R E ((flf) OBLIQUE FRANC 




IN8TITUT 
NATIONAL DE 
LA PROPRIETE 
INDU8TRIELLE 



&n> v mtdfijib Lit 



BREVET D 'INVENTION 




CERTIFICAT D'UTILITE - CERTIFICAT D'ADDITION 



COPIE OFFICIELLE 



Le Directeur general de I'lnstitut national de la propriete 
industrielle eertifie que le document Gi-annexe est la copie 
certifiee conforme d'une demande de titre de propriete 
industrielle deposee a I'lnstitut. 



Fait a Paris, le 2 A JO/fl #gg 



Pour le Directeur general de I'lnstitut 
national de la propriete industrielle 
Le Chef du Departement des brevets 




\<2UC 



BEST AVAILABLE COPY 



Marline PLANCHE 



SIEGE 



I N 3 T I T U T 26 bis, ruo de Saint Petersburg 

NATIONAL DE 75800 PARIS COdex 08 

LA PROPRIETE Telephone : 01 53 04 53 04 

INDUSTRIELLE TflJecopie : 01 42 93 59 30 



OB 267/250298 



ETABLI88EMENT PUBLIC NATION*! f!RF* P«o mniNo «i.4i4 nti <o *»«m 



THIS PAGE BLANK (usptoj 



BREVET D'INVENTIOQLCERTIFICAT D'UTILITE 



■ IHSTITUT 
NATION Al Ol 



IMDUSTMIKLII 

26 bis. rCfe de'Saint Petersbourg * 
75800 Paris Cedex 08 

Telephone : 01 53 04 53 04 Telecopie : 01 42 93 59 30 
' Reserve a I'INPI — 



Code de la propriety intellectuelle-Livre \ 

REQUITE EN D&JVRANCE 

Confirmation cfun depot par telecopie | | 

Cet imptime est a remplir a Tencre noire en lettres capitales 



N° 55-1328 



DATE DE REMISE OES PIECES 
N° D'ENREGISTREMENT NATIONAL 
DEPARTEMENT OE DEPOT 
DATE DE DEPOT 



SUUIL1998 
98 08626" 



0 6 JUIL. 1998 



2 DEMANDE Nature du titre de propnete industrielle 

j>5 brevet d'tnvention C] demande dh/isionnaire 



transformation d'une demande 
de brevet europeen 



demande initiate 



\ certificat d'utilite 

j ! brevet d'invention 

Etablissement du rapport de recherche Q differe Jj£ immediat 

Le demandeur. personne physique, requiert le paiement echefonne de la redevance j j 

Trtre de ('invention (200 caracteres maximum) 



1 NOM ET ADRESSE DU DEMANDEUR OU DU MANDATAIRE 

A QUI LA CORRESPONDANCE DOIT £TRE ADRESS^E 

RINUY, SANTARE1LI 
14 , avenue de la Grande Arm6e 
75017 PARTS 



n°dupouvoirpermanent B ^^|^r^g^nt 01 4Q gjgph°3 43 



certificat d'utilite n" 



Q non 

Proc6d6 et dispositif de communication d f information 



3 DEMANDEUR (S) n* siren • • • _;_•„_.■_ 
Norn et prenoms (souligner le nom patronymique) ou denomination 

CANON KABUSHIKI KAISHA 



code APE-NAF 



Forme juridique 

Aociete de droit 
i aponais 



JAPONAISE 

NationaUte (s) 
Adresse (s) complete (s) 

30-2, Shimomaruko 3-chome, Ohta-ku, 

Tokyo, JAPON 



Pays 

JAPON 



En cas d* insuffisance de place, poursuivre sur papier libre j | 



4 INVENTEUR (S) Les inventeurs sont tes demandeurs 



| | oui ^ non Si la reponse est non. fournir une designation separee 



5 REDUCTION DU TAUX DES REDEVANCES 



| | requtse pour la 1 ere fbis requise anterieurement au depot : joindre copie de la decision d'admission 



6 DECLARATION DE PRIORITY OU REQUtTE DU BENEFICE DE LA DATE DE DEPOT D'UNE DEMANDE ANTtRJEURE 
pays (Torfgfne numero date de depdt 



nature de la demande 



7 DIVISIONS anterieures a la presente demande 




date 



date 



8 Signature du demandeur ou du mani 

(nome^p^^s^J^if^ 
RINUY, S. 



.1206 



SIGNATURE DU PROPOSE A LA RECEPTION ■ SIGNATURE APRES ENREGISTfEMENT DE LA DEMANDE A L'INPI 





I INSTITUT 
NATIONAL OI 
LA PROPRIBTC 



INDUSTatELLK 

BIF021827/FR/EP 

DIVISION ADMINISTRATIVE DES BREVETS 

26bis, rue de Saint-Petersbourg 
75800 Paris Cedex 08 

Tel. : 01 53 04 53 04 - Telecopie : 01 42 93 59 30 



BREVET D'lNVENTIOIBCERTIFICAT D'UTILITE 



DESIGNATION DE L'INVENTEUR 

(si le demandeur n'est pas I'inventeur ou I'unique inventeur) 



U° D'ENREGISTREMENT NATIONAL 



TTTRE DE L'INVENTION : 

Proc6d6 et dispositif de communication d 1 information 



LE(S)SOUSSIGN£(S) 

Soci6t6 de droit Japonais CANON KABUSHIKI KAISHA 



D£SIGNE(NT) EN TANT QU'INVENTEUR(S) (indiquer nom, prenoms, adresse et souligner le nom patronymique) : 

FROUIN Laurent 

2, rue du 6 Juin 1944 

35135 CHANTEPIE, FRANCE. 



NOTA : A titre exceptionnel, le nom de I'inventeur peut fitre suivi de celui de la societe a laquelle il appartient (societe d'appartenance) 
lorsque cel!e-ci est differente de la societe deposante ou titulaire. 

Date et signature (s) du (des) demandeur (s) ou jji^mandataire 
6 juillet 1998 




Bruno QUANT IWj^Yf 2 .1206 
RINUY, SANjEMELLI 




5 



La presente invention concerne un procede et un dispositif de 
1 0 communication d'information. 

Elle s'applique, en particulier, a un reseau a commutation 
asynchrone de paquets, permettant notamment d'interconnecter un petit 
nombre d'equipements multimedia, tout en leur fournissant differentes qualites 
de service pour echanger des donnees. 

15 Le comportement d'un trafic de donnees gener6 par un 

equipement multimedia (ou application) peut s'inscrire dans deux classes de 
service principals, elles-memes divisees, chacune, en deux sous-classes. 
Ainsi le trafic peut etre soit elastique (il s'adapte facilement aux changements 
de conditions de transmission), soit temps reel. SMI est elastique, il peut soit etre 

20 de nature interactive, et done sensible au d6lai de transfert, soit correspondre a 
un transfert massif d'un gros volume de donnees et done sensible a la bande 
passante. S'il s'agit d'un trafic temps reel, soit il est acceptable de perdre 
certains paquets d'information pour privilegier le delai de transmission, le trafic 
est alors appele "deterministe", soit il est preferable de disposer d'un debit 

25 moyen mais sans perte de donn6es, le trafic est alors appele "garanti". 

Le trafic elastique correspond au trafic de type datagramme. Ce 
trafic est dit elastique car il est capable de s'adapter aux conditions de 
transmission sans pour autant perdre de son utilite. Un transfert de fichier 
pourra aussi bien s'ex6cuter via un chemin supportant un debit de 64 kilobit par 
30 seconde que via un chemin supportant un debit de 2 Megabit par seconde. 
Pour le trafic elastique, une premiere classe de base concerne le trafic g6n6re 
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par les applications interactives ou transactionnelles (comme une application de 
type client-serveur), et une seconde classe identifie les donnees vehiculees par 
bloc (comme le transfert de fichiers). 

Les equipements generateurs d'un trafic temps reel requierent un 
5 service deterministe ou garantie. Pour le trafic deterministe, qui privilegie le 
respect d'une contrainte elevee en ce qui concerne le delai de transmission, 
I'application qualifie la bande passante dont elle suppose avoir besoin, ainsi 
que le delai maximal de transmission qu'elle peut accepter. Le reseau privilegie 
ce type de trafic mais se debarasse des donnees pour lesquelles le delai ne 
10 peut etre respecte. II s'agit par exemple de transmission video (en cas de 
problemes de transmission, une image statique apparait) ou de systemes audio 
de qualite moyenne. 

Le service dit garanti se differencie du service deterministe par le 
fait que le reseau ne se debarasse pas volontairement des donnees issues d'un 

15 trafic garanti mais que celui-ci peut etre affecte d'un delai de transmission 
variable en fonction du trafic deterministe plus prioritaire ou au trafic garanti 
concurrent. II s'agit, par exemple, du trafic video haute definition (utilisant des 
techniques de compression). Dans ce cas, le reseau reserve la bande passante 
a I'application qui requiert un service garanti, mais pour gerer les problemes de 

20 gigue (en anglais "jitter") sur les donnees a la reception, Tapplication doit 
posseder des capacites de stockage temporaires des donnees (de Pordre de la 
seconde de trafic), afm de retablir le comportement original du trafic. 

La garantie de la qualite de service exigee par des applications 
concurrentes et de natures differentes passe par la resolution de problemes tels 
25 que la gestion des ressources et le controle de trafic. Les precedes a mettre en 
oeuvre doivent permettre au reseau de fonctionner de fa$on optimale tout en 
fournissant une qualit6 de service acceptable aux differentes applications. Ce 
probleme a fait I'objet de nombreuses 6tudes pour les reseaux a commutation 
de circuits et pour les reseaux a commutation de paquets. 

30 Dans les reseaux a commutations de circuits, la solution connue 

consiste a allouer a chaque connexion une bande passante constante (canal) 
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pendant toute sa duree. Au prealable, une procedure d'acceptation d'appel 
permet au reseau de savoir s'il peut supporter I'appel. Dans le cas ou aucun 
canal n'est disponible, I'appel est rejete. 

Dans les reseaux a commutation de paquets ou le trafic est, par 
5 definition, imprevisible, la nature variable des debits offre I'opportunite d'un 
partage statistique des ressources du reseau. Cette optimisation des 
ressources augmente, malheureusement, les risques de congestion. Ces 
reseaux peuvent etre vus comme une succession de files d'attente a capacite 
limitee dont il convient de controler le remplissage afin d'eviter leur saturation, 
10 synonyme de perte de paquets. 

II est connu de controler le trafic par un mecanisme dit "de 
fenetrage" : lorsqu'un etat de saturation est d6tecte, le recepteur demande 
explicitement a la source de reduire son flux. On parte alors de regulation et de 
controle de flux. 

15 Aucune de ces approches n'est suffisante, la premiere parce 

qu'elle conduit a un gaspillage inevitable des ressources du reseau en allouant 
a la source une bande passante correspondent a son debit maximal et la 
seconde parce que le rapport du temps de propagation sur le temps de 
transmission augmente de maniere considerable lorsque les liaisons sont a tres 

20 haut d6bit. Dans les systemes de controle de flux par retroaction, entre I'instant 
d'emission de la notification de congestion et I'instant de sa reception par le 
noeud source, le trafic d6ja en transit dans le r6seau peut etre considere 
comme definitivement perdu en raison de la congestion, a moins de disposer de 
m§moires de grande capacite pour conserver tous les paquets en transit 

25 pendant I'etat de congestion. 

Par consequent, pour la commutation rapide de paquets, les 
m6thodes de controle purement r§actives sont insuffisantes dans un 
environnement haut d6bit. La commutation necessite des mecanismes 6labor6s 
dans les 6quipements de commutation (noeuds interm6diaires du r§seau) 
30 incluant des methodes preventives et des m6thodes reactives. La technologie 
ATM ("Asynchronous Transfert Mode" ou mode de transfer! asynchrone), 
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propose des techniques de gestion de la qualite de service, et de controle de 
congestion basees sur des rnecanismes elabor6s implementes au sein des 
equipements de commutation. Des exemples de tels rnecanismes sont decrits 
dans les brevets US 5,291,481 et US 5,313,454 qui illustrent aussi la 
5 complexity et le cout potentiel d'implementation de telles methodes. 

Ces methodes ne sont done pas adaptees a des reseaux 
comprenant un nombre plus restreint d'equipements a interconnecter ou le coOt 
des moyens de communication ne doit pas etre trop eleve par rapport au cout 
des equipements a interconnecter. 

10 Des tentatives d'utilisation de commutateurs ATM embarques ont 

ete faites, telles que celle decrite dans la these "Architecture distribute temps 
r6el fondee sur ATM" de Jean-Frangois Guilaud (INPG). Cette these mentionne 
I'utilisation de la signalisation ATM classique afin de permettre la gestion des 
connexions, ce qui represente une implementation complexe. Cependant, la 

15 mise en oeuvre complete des rnecanismes de gestion des connexions doit 
prevoir d'eviter la congestion, qui, afin de simplifier I'utilisation du commutateur, 
reposent sur une gestion locale des informations de charge et sur Putilisation 
des files d'attente en sortie pour chaque commutateur. 

Le controle de flux strict, a la source, tel qu'il est decrit dans la 
20 these, prevoit Tutilisation d'un mode connecte uniquement, et verifie le non 
depassement du transfert de donnees par rapport a ce qui a ete prevu lors de 
Tetablissement de la connexion correspondante. Cela peut done engendrer une 
mauvaise utilisation des ressources reseau ainsi qu'un manque de flexibility du 
systeme. 

25 Par ailleurs, il n'est envisage aucun moyen simple pour reagir au 

probleme de congestion si ce n'est en se reposant sur les solutions d6crites 
pr6cedemment, propre a I'utilisation de TATM, mais qui demeurent des 
solutions complexes. 

De plus, I'utilisation d'une dimension de paquet fixe, 
30 conformement a TATM, engendre une perte fixe du debit utile par lien du reseau 
disponible. En revanche, une taille de paquet variable en fonction de la charge 
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du reseau permet d'optimiser le debit utile. Les techniques de controle de la 
taille des paquets ont deja ete testees sur des architectures r6seau de type bus 
ou anneau. 

La commutation asynchrone de paquets, telle que decrite dans la 
5 norme IEEE-P1355, est basee sur une technologie de commutation (matrice de 
commutation non bloquante permettant plusieurs chemins simultanes) a faible 
cout de realisation en ce qui concerne le commutateur. En effet, le 
commutateur en question n'utilise qu'un minimum de ressources pour effectuer 
la commutation d'un paquet a partir d'un port d'entree vers un port de sortie. Le 
10 transfer! d'un paquet au travers du commutateur a lieu des que le commutateur 
a connaissance des informations de commutation du dit paquet (en-t§te de 
paquet) sans attendre la complete reception de toutes les donnees du paquet. II 
n'y a done aucune gestion de file d'attente ou de priorite dans les noeuds 
intermediates du chemin. 

15 Par ailleurs, afm de regler les problemes de contention d'acces a 

un port d'entree (respectivement vers un port de sortie) du commutateur, 
lorsque plusieurs paquets sont a priori destines a transiter via ce port d'entree 
(respectivement de sortie), un mecanisme de controle de flux au niveau du lien 
est implements, n'autorisant une source a transmettre des donnees sur la ligne 

20 de transmission que lorsqu'elle a obtenu Pautorisation de la part de la 
destination, e'est-a-dire lorsqu'un groupe de donnees precedemment emises 
par la source ont ete acquittees par la destination. 

Cependant, la commutation asynchrone de paquets, telle que 
connue dans Tetat de la technique, si elle laisse envisager des couts 
25 d'implementation attractifs, ne pr6voit pas de garantir differentes qualites de 
sen/ice pour les trafics concurrents au sein d'un meme reseau. 

Les technologies de type bus s6rie proposent une alternative a 
I'utilisation de la commutation de paquets pour interconnecter des p6riph6riques 
a moindre cout. En effet, les mecanismes mis en oeuvre pour partager les 
30 ressources se trouvent simplifies du fait de Tunicit6 de la ressource principale, 
en Toccurrence le medium de communication. Cette simplicit§ implique aussi 
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I'inconvenient d'une bande passante limitee : la bande passante moyenne 
disponible par terminal diminue en fonction du nombre de terminaux connectes. 

Certaines technologies bus serie, telles que celle normalisee par 
TIEEE, reference P1394, definie pour Interconnexion d'equipements 
5 multimedia, supportent le transfert des donnees selon principalement deux 
classes de service en mettant en oeuvre une architecture logique de type bus. 
Des mecanismes sont done necessaires pour arbitrer I'acces au bus et 
organiser le transfert des donnees. Cette technologie de bus serie prevoit un 
mecanisme de reservation de ressources. II permet, d'une part, la transmission 
10 de donnees dite isochrone, comprenant une phase de reservation, et, d'autre 
part, la transmission de donnees dite asynchrone, sans phase de reservation. 

Le brevet US 5,243,595 presente un reseau d'architecture bus de 
type non connects adapte a transmettre des messages de controle et qui 
supporte le transport des donnees en mode non connecte, et illustre I'interet de 
1 5 combiner les deux modes de transfert de donnees. 

Le but de l'invention est similaire a celui de Tarchitecture de bus 
s6rie IEEE-P1394, & savoir la combinaison de transfert de donnees de type 
asynchrone (non-connecte) et de transfert de donnees isochrone (connecte). 

L'invention vise a permettre, sur un reseau a commutation de 
20 paquet d'une part, la transmission de donnees en mode connects, comprenant 
une phase de reservation de ressources du reseau et, d'autre part, la 
transmission de donnees en mode non connecte, sans phase de reservation de 
ressources. 

L'invention a aussi pour objet de garantir une qualite de service 
25 selon plusieurs classes de service, par exemple, deterministe, garanti et 
glastique. 

L'invention a aussi pour buts : 

- d'effectuer un controle d'admission des connexions, 



- d'effectuer un controle distribue sur la charge du r6seau afin de 
garantir la coherence de reformation relative a la charge du reseau, dans tous 
les dispositifs de communication du reseau, et 

- de deporter au dispositif de communication source, la gestion des 
ressources associees a la garantie de service requise par un type de trafic. 

A cet effet, la presente invention vise, selon un premier aspect, un 
procede de communication entre des dispositifs de communication d'un reseau 
a commutation de paquet comportant au moins un commutateur, caracterise en 
ce qu'il comporte une operation de determination de mode de transmission, au 
cours de laquelle, pour chaque information a transmettre, on determine un 
mode de transmission, connecte ou non, puis 

- pour chaque information a transmettre en mode connecte : 

• une operation de reservation de chemin sur ledit reseau, 
puis 

• une operation de transmission de ladite information, en 
mode connecte, sur le chemin reserve au cours de 
Poperation de reservation, et 

- pour chaque information & transmettre en mode non connecte : 

• une operation d'estimation de disponibilite de chemin sur 
ledit reseau, puis, lorsqu'un chemin est estime disponible 
pour la transmission de ladite information, 

• une operation de transmission de ladite information, sur 
ledit chemin, en mode non connecte. 

Grace a ces dispositions, la transmission des informations a 
transmettre en mode non connecte n'est effectuee que s'il est estim6 que cette 
transmission peut etre effectuee. Le risque de congestion du reseau est done 
limite, alors meme que Ton autorise des transmissions en mode non connecte. 

Ainsi, le procede de I'invention permet aussi bien la transmission 
de donnees de duree courte (message), qui correspondent a des transmissions 
en mode non connects, que les transmissions de longue dur6e (vid§o) qui 
correspondent a des transmissions en mode connecte. 
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Selon des caracteristiques particulieres, I'operation de reservation 
de chemin comporte une operation de transmission, sur ledit chemin, d'un 
message comportant des informations representatives du service requis pour la 
transmission en mode connecte. 

5 Grace a ces dispositions, chaque dispositif de communication est 

informe du service requis pour la transmission envisagee. Cette information est 
identique pour chaque dispositif de communication du reseau, mais elle 
n'impose aucun parametre de transmission aux dispositifs de communication, 
ceux-ci pouvant tenir compte de leurs propres contraintes. 

10 Selon d'autres caracteristiques particulieres, I'operation de 

reservation de chemin sur ledit reseau, comporte une operation de mise a jour 
d'une table de charge conservee par chaque dispositif de communication du 
reseau. 

Grace a ces dispositions, chaque dispositif de communication 
15 conserve une information de charge relative au reseau, sous forme de table de 
charge, et cette information, est mise a jour a chaque fois qu'une transmission 
en mode connecte est etablie. La gestion de la charge du reseau et Testimation 
de disponibilite d'un chemin sont done grandement facilitees. 

Selon d'autres caracteristiques particulieres, au cours de 
20 I'operation d'estimation de disponibilite, on prend en compte des valeurs 
conservees dans la table de charge du dispositif de communication qui a au 
moins une information a transmettre. 

Grace a ces dispositions, I'estimation de la disponibilite d'un 
chemin pour une communication en mode non connecte est effectuee en 
25 prenant en compte la charge du reseau liee aux communications en mode 
connect6. 

Selon d'autres caracteristiques particulieres, I'operation de mise a 
jour de table comporte une operation de determination de parametres 
representatifs du service requis pour la transmission en mode connecte. 
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Grace a ces dispositions, chaque table de charge est mise a jour 
en prenant en compte le service requis pour la transmission en mode connecte. 
Cependant, chaque dispositif de communication peut tenir compte de ses 
propres contraintes (les nombres de paquets qu'il a a emettre dans chacun des 
modes de transmission, par exemple), pour determiner lesdits parametres. 

Selon d'autres caracteristiques particulieres, ['operation de mise a 
jour de table de charge comporte une operation de mise en memoire de la 
bande passante disponible pour chaque lien du reseau faisant partie d'un 
chemin associe a une connexion. 

Grace a ces dispositions, le procede de I'invention permet de faire 
varier la taille des paquets et de prendre en compte la variation de charge qui 
en resulte. 

Selon d'autres caracteristiques particulieres, Toperation de 
reservation de chemin comporte une operation de verification, par chaque 
dispositif de communication intermediate sur ledit chemin, de la disponibilite du 
chemin a reserver. 

Grace a ces dispositions, ce sont les dispositifs de communication 
intermediaires qui resolvent les problemes de conflits d'acces a un lien. Les 
eventuelles differences entre les tables de charges des differents dispositifs de 
communication du reseau sont ainsi cornpensees par Taction des dispositifs de 
communication intermediaires du chemin associe a une connexion. 

Selon d'autres caracteristiques particulieres, I'operation d'estimation 
consiste a determiner si au moins un chemin est au moins partiellement 
disponible pour la transmission en mode non connecte. 

Grace a ces dispositions, le trafic elastique peut faire I'objet de 
communication en mode non connecte. La gestion des transmissions en mode 
non connecte, s'effectue done en prenant en compte, d'une part, la 
connaissance de la charge du reseau liee au trafic connecte et, d'autre part, la 
connaissance partielle (la connaissance locale) de la charge du reseau Ii6e au 
trafic non connecte. 
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Les transmissions en mode non connecte presentent alors 
pratiquement les memes avantages que les transmissions en mode connecte, 
puisque les risques de congestion sont tres limites. 

Selon d'autres caracteristiques particulieres, le reseau met en 
5 oeuvre le protocole de communication IEEE 1355. 

Grace a ces dispositions, le reseau beneficie d'un protocole fiable 
mettant en oeuvre un routage a la source, le controle de flux au niveau des 
liens et des paquets de taille variable. 

Selon un deuxieme aspect, la presente invention vise un dispositif 
10 de communication sur un reseau a commutation de paquet comportant au 
moins un commutateur, caracterise en ce qu'il comporte : 

- un moyen de determination de mode de transmission adapte a 
determiner, pour chaque information a transmettre, un mode de transmission, 
connecte ou non, 

15 - un moyen de reservation adapte, pour chaque information a 

transmettre en mode connecte, a reserver un chemin sur ledit reseau, 

- un moyen d'estimation de disponibilite de chemin adapte, pour 
chaque information a transmettre en mode non connecte, a estimer la 
disponibilite d'au moins un chemin, et 

20 - un moyen de transmission adapte, d'une part, a transmettre en 

mode connecte chaque information a transmettre en mode connecte, sur le 
chemin reserve par le moyen de reservation, et, d'autre part, a transmettre en 
mode non connecte, sur un chemin estime disponible par le moyen d'estimation 
de disponibilite, chaque information a transmettre en mode non connecte. 

25 L'invention vise aussi un ordinateur, une camera, un t6l6copieur, 

un appareil photographique, un televiseur, une imprimante, un scanner et un 
lecteur audio/video, caracteris6s en ce qu'ils comportent un dispositif tel que 
succinctement expose ci-dessus. 



L'invention vise aussi : 
30 - un moyen de stockage d'informations lisible par un ordinateur ou 

un microprocesseur conservant des instructions d'un programme informatique 
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caracterise en ce qu'il permet la mise en oeuvre du procede de I'invention telle 
que succinctement exposee ci-dessus, et 

- un moyen de stockage d'informations amovible, partiellement ou 
totalement, et lisible par un ordinateur ou un microprocesseur conservant des 

5 instructions d'un programme informatique caracterise en ce qu'il permet la mise 
en oeuvre du procede de I'invention telle que succinctement exposee ci-dessus. 

Les caracteristiques preferentielles ou particulieres, et les 
avantages de ce dispositif, de cet ordinateur, de cette camera, de ce 
telecopieur, de cet appareil photographique, de ce televiseur, de cette 
10 imprimante, de ce scanner, de ce lecteur audio/video et de ces moyens de 
stockage d'informations etant identiques a ceux du procede tel que 
succinctement expos6 ci-dessus, ces avantages ne sont pas rappeles ici. 

D'autres avantages et caracteristiques de Pinvention ressortiront 
de la description qui va suivre, faite en regard des dessins annexes dans 
15 lesquels : 

- la figure 1 represente un reseau de noeuds interconnects, 

- la figure 2 represente un dispositif (ou "moyen") de communication 
selon la presente invention, 

- la figure 3 represente des echanges de messages intervenant 
20 entre un noeud source et un noeud destinataire pour vehiculer d'une part un 

trafic connecte et, d'autre part, un trafic non connecte, 

- la figure 4 represente un organigramme mis en oeuvre par le 
moyen de communication du noeud dit "source" pour une transmission en 
mode connecte, 

25 - la figure 5 represente un organigramme mis en oeuvre par un 

moyen de communication d'un noeud dit "intermediaire" pour une transmission 
en mode connecte, 

- la figure 6 represente un organigramme mis en oeuvre par un 
moyen de communication d'un noeud dit "destinataire" pour une transmission 

30 en mode connects, 
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- la figure 7 represente un organigramme mis en oeuvre par un 
moyen de communication d'un noeud dit "voisin" pour une transmission en 
mode connecte, 

- la figure 8 represente un reseau sur lequel circulent des 
messages de controle destines a la gestion du mode connecte, 

- la figure 9 represente la structure de messages de controle 
destines a la gestion du mode connecte, 

- la figure 10 represente la structure de donnees d'une table de 
charge en memoire d'un moyen de communication, 

- la figure 11 represente la structure de donnees d'une table de 
specifications et de priorites contenant des canaux virtuels reserves a la 
transmission en mode connecte, en m6moire d'un moyen de communication, 

- la figure 12 represente un organigramme d'emission en mode 
connecte et en mode non connecte d'un moyen de communication tel qu'illustre 
en figure 2, 

- la figure 13 represente un organigramme de determination, par le 
noeud source, de disponibilite de chemin pour I'etablissement d'une connexion, 
incorpore dans Torganigramme de la figure 4, 

- la figure 14 represente un organigramme de determination, par un 
noeud intermediaire ou le noeud destinataire, de disponibilite de chemin pour 
Petablissement d'une connexion, incorpore dans I'organigramme de la figure 5 
ou 6, et 

- la figure 15 represente un organigramme de determination, par un 
noeud voisin, de disponibilite de chemin pour I'etablissement d'une connexion, 
incorpore dans I'organigramme de la figure 7. 

Dans toute la pr6sente demande les termes "dispositifs de 
communication M et "moyen de communication" ont la meme signification et 
d6signent les memes combinaisons de moyens objets de la pr6sente invention. 

Le mode prefere de realisation gere trois classes de service 
sp6cifiques, d6terministe (en mode connecte), garantie (en mode connecte) et 
elastique (en mode non connecte), sur un reseau & commutation de paquet. 
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En figure 1, on observe cinq equipements multimedias 101 a 105 
cTun reseau a commutation de paquet 100, relies entre eux par six liens 106 a 
111. Chaque equipement multimedia comporte un moyen de communication 
112 et un moyen de traitement de donnees 113. Le moyen de communication 
5 112 permet au moyen de traitement 113 d'ouvrir une connexion dediee a un 
trafic connecte (trafic temps reel deterministe ou garanti) puis de generer ce 
trafic, ou bien de generer directement un trafic non connecte (trafic elastique). 

Lorsque I'equipement multimedia 101 envoie un paquet de 
donnees a Pequipement multimedia 105, par I'intermediaire des liens 108 et 
10 110, I'equipement 101 est un noeud "source", I'equipement 105 est un noeud 
"destinataire", I'equipement 102, par lequel transitent les donnees, est un noeud 
"intermediate", tandis que les noeuds 103 et 104 sont des noeuds "voisins", 
aucune des donnees transmises ne transitant par Tun d'entre eux. 

Le mode de realisation decrit et represents concerne un reseau 
15 local compose de plusieurs noeuds interconnects par des liens bidirectionnels 
rapides. Chaque noeud incorpore un commutateur non bloquant possedant une 
matrice de commutation a reception et emission simultanees (en anglais "cut- 
through crossbar") et possede un certain nombre de ports externes auxquels 
peuvent etre raccordes des liens. Dans un tel reseau, la route ou le chemin 
20 suivi par un paquet est une succession de liens, chacun des liens etant d6fini 
par les deux noeuds qu'il rejoint. 

La communication sur un tel reseau est dite "cornmutee". Un 
exemple d'un tel r6seau est donne par un systeme utilisant des composants 
selon la norme IEEE 1355. 

25 En figure 2, on observe un schema bloc d'un moyen de 

communication 112 du reseau, comportant un composant commutateur/routeur 
209 couple £ une unite centrale 206 (d6composee en deux entites 206A et 206 
B). 

Le composant commutateur/routeur 209, constitu6 d'un 
30 composant de la marque SGS-THOMSON (marque depos6e), reference ST 
C104, comporte des ports physiques reltes a un connecteur 230, et deux ports 
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internes dont Tun est dedie au controle, relies a I'unite centrale 206 par 
I'intermediaire de differents composants decrits ci-dessous. 

On observe ici que le composant commutateur/routeur 
susmentionne 209 ST C104 possede, en fait, trente-deux ports physiques en 
5 plus de deux ports de controle, seulement un port de controle et quelques ports 
physiques etant representes en figure 2. Des composants d'interface 213 et 
216 sont relies aux deux ports internes du cornposant commutateur/routeur 209 
et sont, chacun, bas6s sur un composant reference ST C101 et fabrique sous la 
marque SGS-THOMSON. 

10 Le composant commutateur/routeur 209 et les composants 

d'interface 213 et 216 effectuent un codage conforme a la norme IEEE 1355. Le 
composant commutateur/routeur 209 est a architecture de type non bloquante. 

Des emetteur/recepteurs, non representes, plus connus sous leur 
denomination technique de langue anglaise " transceiver convertissent des 
15 signaux TTL, sur les ports physiques du composant commutateur/routeur 209 
en signaux differentiels sur le connecteur 230. 

Les emetteurs/recepteurs sont, par exemple, des composants de 
la marque AT&T (marque deposee) references 1141 MK. 

Le connecteur 230 est destine a etre relie a plusieurs connecteurs 
20 identiques incorpores a d'autres moyens de communication du reseau. lis sont 
de la marque deposee HARTING et de reference 2721-121-8000. 

Les composants d'interface 213 et 216 sont relies, par une liaison 
parallele, a une interface PCI 208, elle-meme reliee a un bus PCI 231. 
L'interface 208 est, par exemple, composee d'un circuit AMCC (marque 
25 deposee) S5933. Le bus PCI 231 est, en outre, relie : 

-Sun composant d'interface 232, identique au composant 208, lui- 
meme reli6 au moyen de traitement 113 (figure 1) ; 

- a une interface de controle 203, par exemple constitute d'un 
composant 82439 HX de marque INTEL ©, lui meme relie a un bus local d'unit6 
30 centrale 206, comportant un microprocesseur 206A et une memoire cache 
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statique 206B, et a une memoire dynamique 204 (constitute des deux entites 
204A et 204 B) ; et 

- a un composant d'interface 205, par exemple de reference 
82371 5B de marque INTEL ©, ce composant etant relie a un bus ISA qui relie 
5 un controleur ISA de peripheriques 233, a une memoire flash de systeme 
d'exploitation BIOS 234, a une horloge temps-reel 235 et a une extension de 
memoire flash 236. 

L'architecture et les composants du moyen de communication 112 
sont bien connus de ITiomme du metier des systemes informatiques et ils ne 
1 0 sont pas plus detailles ici. 

Pour une meilleure compr6hension de la constitution du mode de 
realisation decrit et represents, le lecteur est invite a consulter les notes 
d'utilisation des composants, notes fournies par leurs constructeurs respectifs. 

L'unite centrale de traitement CPU 206 est compos6e d'un 
15 microcontroleur 206A de la marque depos6e INTEL et de reference PENTIUM 
(marque deposee) avec 32 Mo de m6moire vive dynamique DRAM 204 a titre 
de memoire de travail, 256 Ko de memoire statique cache 206B. 

On observe ici que Texpression "segment de memoire" utilis§e ci- 
dessous d6signe, dans chacune des memoires, aussi bien une zone memoire 
20 de faible capacite (ne conservant que quelques donnees binaires), qu'une zone 
m6moire de grande capacite (permettant de stacker un programme entier). 

La memoire vive 204A conserve des donnees, des variables et 
des r6sultats interm6diaires de traitement utilises par les programmes stockes 
en memoire 204B, dans des segments de m6moire portant, dans la suite de la 
25 description, les memes noms que les donnees dont ils conservent les valeurs. 

En cours de fonctionnement, la memoire flash 204B contient le 
BIOS et les logiciels de controle (qui operent avec le systeme d'exploitation 
temps-r6el CHORUS (marque deposee)) qui sont decrits en figure 3 a 7. 

La memoire vive 204 comporte notamment : 
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un segment de memoire " userjdata " dans lequel sont 
conservees les informations utilisateur a transmettre, dont, en particulier, le 
service requis (comportant la bande passante necessaire), 

- un segment de memoire " addjdata " dans lequel sont conservees 
5 des informations additionnelles a transmettre, informations qui definissent, 

notamment, dans son integralite, le chemin a suivre par les donnees utilisateur 
sur le reseau de communication (figure 9), et 

- un segment de memoire " Tables " dans lequel sont conservees 
une table de charge de chemins et une table de charge de liens comportant des 

10 informations decrivant tous les chemins dont le noeud considere est la source 
et tous les liens faisant partie de ces chemins (figures 10 et 1 1 ). 

La zone d'extension de memoire 236 est adaptee a conserver : 

- le programme de fonctionnement de Tunite centrale de traitement 
206, dans un segment de memoire " programl ", et 

15 - un identificateur representatif du moyen de communication 112, 

identificateur qui est unique sur le reseau de communication. 

A Initialisation du moyen de communication, le programme stocke 
dans la memoire d'extension 236 est au moins partiellement copie et organise 
dans la zone memoire d'execution 204B. 

20 La zone d'extension de memoire 236 constitue un moyen de 

stockage d'informations lisibles par un ordinateur ou un microprocesseur, 
conservant des instructions d'un programme informatique caract6rise en ce qu'il 
permet la mise en oeuvre du procede de I'invention. Selon une variante, la zone 
d'extension de memoire 236 est amovible, partiellement ou totalement, et 

25 comporte, par exemple, une bande magnetique, une m6moire flash, une 
disquette ou un compact disque £ memoire figee ("CD-ROM" en anglais). 

Dans le mode de r6alisation decrit et repr6sent6, le moyen de 
traitement utilise le moyen de communication conforme a I'invention. Le moyen 
de traitement demande Tetablissement d'une connexion au moyen de 
30 communication en lui faisant part du service requis ("application requirement" 
en anglais). Ces parametres dits de "service requis" sont, d'une part, transmis 
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dans certains messages de signalisation et, d'autre part, utilises pour calculer 
les parametres de transmission ("trafic parameters" en anglais). Le service 
requis est I'etalon utilise pour la mise a jour des tables de charges dans les 
differents noeuds du reseau car il ne depend pas de I'etat respectif des tables 
5 de charges. 

Les organigrammes objets des figures 4 a 7 n'illustrent que 
partiellement le fonctionnement des dispositifs de communication. 

L'unite centrale de traitement 206 est adaptee a mettre en oeuvre 
les organigrammes decrits en figures 4 3 7. 

10 En figure 3, on observe, symbolis6s par des fleches descendantes 

placees dans une colonne centrale, des messages transmis sur le reseau, entre 
un noeud source, a gauche, et un noeud destinataire, a droite. Les fleches 
orientees de la gauche vers la droite correspondent a des messages transmis 
depuis le noeud source des donn6es utilisateur a destination du noeud 

15 destinataire de ces donnees et les fleches orient6es de la droite vers la gauche 
correspondent a des messages transmis depuis le noeud destinataire des 
donnees utilisateur vers le noeud source de ces donnees. 

Dans la colonne de gauche, sont representes les messages 
echang6s entre le moyen de traitement du noeud source (3 gauche) et le 
20 moyen de communication du noeud source droite de la colonne de gauche). 
Dans la colonne de droite, sont represent§s les messages echanges entre le 
moyen de traitement du noeud destinataire (3 droite) et le moyen de 
communication du noeud destinataire (3 gauche de la colonne de droite). 

Les six fleches 251 & 256 de la colonne centrale correspondent £ 
25 un mode de communication connecte conforme a la presente invention, les 
fleches 257 et 258 correspondent a une transmission en mode non connects 
avec synchronisation des deux moyens de traitement et la fteche 259 
correspond & une communication en mode non connect6 sans synchronisation 
des deux moyens de traitement. 
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Dans la colonne centrale, les fleches 254, 257, 258 et 259 
correspondent 3 des transferts de donn6es sur le reseau, les autres fleches 
correspondant a des messages organisant ces transferts. 

En mode connecte, c'est-a-dire dans le cas du trafic connecte, le 
5 moyen de traitement du noeud source informe le moyen de communication du 
noeud source de Pouverture d'une connexion en lui envoyant un message de 
requete de connexion ("connect^req") 

En consequence, le moyen de communication du noeud source 
lance la phase d'initialisation ("set-up" en anglais). Cette phase comporte 
10 notamment remission d'un message d'initialisation 251 (message "set-up") par 
le moyen de communication du noeud source et a destination du moyen de 
communication du noeud destinataire (par I'intermediaire, le cas echeant, du 
moyen de communication de chaque noeud intermediate). 

A reception du message de "set-up", le moyen de communication 
15 du noeud destinataire informe le moyen de traitement du noeud destinataire 
qu'il a regu une demande d'ouverture de connexion, par Pintermediaire d'un 
message de demande d'ouverture de connexion " connect Jncf\ 

Si la demande est acceptee, le moyen de communication du 
noeud destinataire est informe* par le moyen de traitement du noeud 

20 destinataire, par I'intermediaire d'un message "connectjans" (identifie en figure 
6 par le nom "callRequest_acK x pour acceptation de requete d'appel ou de 
"callRequest_nacK\ pour rejet de requete d'appel, selon le resultat de la demande 
d'ouverture de connexion, operations 377 et 378 respectivement. Dans le premier 
cas, un message de connexion 252 ("connect) est emis par le moyen de 

25 communication du noeud destinataire vers le moyen de communication du 
noeud source. 

Le moyen de traitement du noeud source est alors inform6 du bon 
d6roulement de Pouverture de la connexion par un message de confirmation de 
connexion "connect_cfr'\ de la part du moyen de communication du noeud 
30 source. Le moyen de communication de chaque noeud du reseau est alors 
informe de Petablissement d'une nouvelle connexion par Pintermediaire d'un 
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message 253 de rnise a jour de table de charge "LinkTabLoad" diffuse par le 
moyen de communication du noeud source. Ce message est aussi utilise pour 
confirmer aupres des noeuds intermediaires et du noeud destinataire le bon 
deroulement de la phase d'etablissement de la connexion. 

5 Le transfer! de donnees composant le trafic connecte associe a la 

connexion, du noeud source vers le noeud destinataire, peut alors avoir lieu. A 
cet effet, le moyen de traitement du noeud source et le moyen de 
communication du noeud source echangent des messages de demande 
d'emission d'un message de donnees "sendlsoData_req" et de confirmation 
10 d'emission du message de donnees n sendlsoData_cfr". 

Le transfert des messages de donnees 254 est alors effectue 
apres segmentation du flot de donnees en paquets de taille predefinie. Le 
moyen de communication du noeud destinataire regoit les paquets de donn6es 
qu'il confie au moyen de traitement du noeud destinataire, par I'interrnediaire du 
15 message de reception d'un message de donnees "sendlsoData__ind") t apres 
avoir restructure le flot de donnees. 

Lorsque les donnees a transmettre ont ete transmises, le moyen 
de traitement du noeud source peut decider de la fermeture d'une connexion en 
transmettant un message de demande de fermeture de connexion 
20 " release_req" au moyen de communication du noeud source. 

Le moyen de communication du noeud source emet alors : 

- un message de confirmation de relachement "release__cfr" a 
destination du moyen de traitement du noeud source, 

- un message de relachement "release" 255 a destination des 
25 eventuels noeuds intermediaires et du noeud destinataire, et 

- un message 256 de mise a jour de table de charge "LinkTabFree" 
a tous les noeuds du reseau. 

Le message 256 est utilise pour confirmer aupres des noeuds 
intermediaires, des noeuds voisins et du noeud destinataire le bon deroulement 
30 de la phase de liberation de la connexion. Au niveau du noeud destinataire, le 
moyen de communication informe le moyen de traitement de la fermeture de la 
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connexion par I'intermediaire d'un message de notification de fermeture de 
connexion "releasejnd". 

Le transfert de donnees pour le trafic elastique, en mode non 
connecte avec synchronisation des moyens de traitement, se fait sans 
5 ouverture prealable d'un connexion, par la transmission du message d'emission 
de message "sendSyncData_req" par le moyen de traitement du noeud source 
vers le moyen de communication du noeud source. Ce moyen de 
communication effectue le transfert 257 des donnees apres segmentation du 
Hot de donnees en paquets de taille predefinie. Au niveau du noeud 

10 destinataire, la reception des donnees est effectuee par le moyen de 
communication, qui informe le moyen de traitement, et transmet le flot de 
donnees restructure, par Pusage du message de reception de message 
"sendSyncDataJnd". En reponse, le moyen de traitement du noeud destinataire 
emet, a destination du moyen de communication du noeud destinataire, un 

15 message de bonne reception "sendSyncData_ans", qui contient la reponse du 
moyen de traitement du noeud destinataire et provoque le transfert d f un 
message 258 entre le moyen de communication du noeud destinataire et le 
moyen de communication du noeud source. A reception de ce message 258, le 
moyen de communication du noeud source emet a destination du moyen de 

20 traitement du noeud source un message de confirmation de transmission 
"sendSyncData^fr". 

Le transfert de donnees pour le trafic elastique, en mode non 
connecte sans synchronisation des moyens de traitement, se fait sans 
ouverture prealable d'un connexion, par la transmission du message d'emission 

25 de message "sendAsyncData_req" par le moyen de traitement du noeud source 
vers le moyen de communication du noeud source. Ce moyen de 
communication effectue le transfert 259 des donn§es apres segmentation du 
flot de donnees en paquets de taille predefinie et 6met a destination du moyen 
de traitement du noeud source un message de confirmation de transmission 

30 n sendAsyncData_cfr". Au niveau du noeud destinataire, la reception des 
donnees est effectuee par le moyen de communication, qui informe le moyen 
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de traitement et transmet le Hot de donnees restructure, par I'usage du 
message de reception de message "sendAsyncData_in<f\ 

Les figures 4 a 7 illustrent les procedures de gestion des 
connexions selon Pinvention. 

5 En ce qui concerne le moyen de communication du noeud source, 

apres avoir ete dans un etat d'initialisation 300 (figure 4), un message entrant 
"connect_req" est regu au cours d'une operation 301 , de la part du moyen de 
traitement du noeud source. Ce message comporte le service requis, dont la 
bande passante, et le mode de transmission. Le moyen de communication du 
10 noeud source effectue alors la selection d'un chemin alloue a la connexion, le 
calcul des parametres de transmission en fonction du service requis puis la 
mise a jour de la table de charge si un chemin est disponible (figure 13), au 
cours d'une operation 302. 

Ensuite, au cours d'un test 304, le moyen de communication du 
15 noeud source determine si la bande passante n6cessaire a la connexion 
envisagee est disponible sur le chemin selectionne, ou non. Cette procedure de 
test 304 est connue sous le nom de " Controle d'Admission de Connexion " ou 
encore "CAC". Lorsque le resultat du test 304 est negatif, au cours d'une 
operation 303, le moyen de communication emet un message de refus 
20 d'ouverture (message "connect^cfr" negatif) de communication a destination du 
moyen de traitement du noeud source. Ce message de refus "connect_cfr" 
negatif a pour effet d'avertir I'application logicielle qui avait requis la 
transmission de I'impossibilite d'effectuer cette transmission en mode connecte. 

Ensuite, les ressources associ6es a la gestion de la connexion 

25 sont liberees. 

Lorsque le resultat du test 304 est positif, au cours d'une operation 
305, le moyen de communication emet le message 251 "set-up" (figure 3) & 
destination du moyen de communication du noeud destinataire, par 
I'intermediaire de chacun des dispositifs de communication des 6ventuels 
30 noeuds intermediaires. Ce message 251 decrit la connexion d etablir (voir figure 

9). 
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Ensuite, au cours d'une operation 306, un compteur d'horloge (en 
anglais "timer") "cncAckWaif est initialise a une valeur qui correspond a un 
delai maximum accorde a Petablissement de la connexion demandee. Le 
moyen de communication se met alors dans un etat d'attente de la reponse du 
5 reseau quant a Petablissement de la connexion, etat 307. 

Dans cet etat 307, trois evenements differents peuvent se 
produire, au cours d'operations 308, 310 ou 31 1 . 

Lorsque, dans Petat 307, le message entrant est un message 
"cncAckWaiF, provenant du passage a zero de la valeur du compteur de 

10 signaux d'horloge "cncAckWaif initialise au cours de Poperation 306, operation 
308, ou lorsque le message entrant est un message " release jDacK\ provenant 
du noeud destinataire ou de Tun des eventuels noeuds intermediates, 
operation 310, Poperation 323 est effectuee, au cours de laquelle le moyen de 
traitement du noeud source est informe du rejet de la demande de connexion. A 

15 cet effet, le moyen de communication du noeud source emet un message 
n openCall_nacK\ correspondent a un message "connect__cfr" negatif, notifiant le 
rejet de la connexion, a destination du moyen de traitement du noeud source. 

A la suite de Poperation 323, au cours d'une operation 324, le 
moyen de communication du noeud source precede a la mise a jour des tables 
20 de charge associees a la connexion qui a ete rejetee. Puis, au cours d'une 
operation 325, les ressources associees a la gestion de la connexion sont 
liberees. 

Enfin, lorsque, dans Petat 307, le message entrant est un 
message de connexion 252 "connect 1 , provenant du noeud destinataire, 

25 operation 31 1, le moyen de communication du noeud source effectue P6mission 
d'un message d'acquittement d'ouverture de connexion "openCall_ack\ 
correspondant a un message "connect_cfr" positif, a destination du moyen de 
traitement du noeud source, operation 312, puis, au cours d'une operation 313, 
diffuse un message 253 "LinkTabLoad" comportant notamment la description 

30 du service requis, la bande passante utilisee ainsi que la description du chemin 
correspondant a la connexion, en termes de liens. Ce message est diffuse a 
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destination de tous les noeuds du reseau, ce qui a pour effet que chaque noeud 
du reseau met a jour ses tables de charge. La diffusion de ce message est 
effectuee en suivant un arbre de recouvrement du reseau, determine selon des 
techniques connues (voir figure 8). 

5 Le moyen de communication du noeud source se met alors dans 

I'etat 314 au cours duquel il attend une evolution de la connexion et transmet 
toutes les donn6es destinees a etre transmises en mode connecte, sur la 
connexion mise en place. 

Deux messages peuvent alors entrer dans le moyen de 
1 0 communication, au cours d'operations 31 5 et 31 8. 

Lorsque, dans I'etat 314, le message entrant est un message de 
relachement provenant d'un autre noeud du reseau "release_bacK\ op6ration 
315, le moyen de communication du noeud source emet un message de 
terminaison de communication "callTerminate", "releasejnd" figure 3, a 
15 destination du moyen de traitement du noeud source, operation 316, ce qui a 
pour effet d'informer le moyen de traitement de la fermeture de la connexion. 

Puis, le moyen de communication emet un message d'alarme 
"alarm_dcnBack\ operation 317, a destination du moyen de traitement du 
noeud source, ce qui a pour effet de declencher le traitement d'une alarme par 
20 ce moyen de traitement puisque la connexion a ete interrompue de manfere 
anormale. Puis, le moyen de communication diffuse a destination de tous les 
autres noeuds du reseau, un message de mise a jour de tables de charges 
"LinkTabFree", comportant notamment une description du service requis et du 
chemin correspondant a la connexion, en termes de liens, operation 320. 

25 Le moyen de communication effectue alors une operation 321, 

identique a Pop§ration 324, puis une operation 322 au cours de laquelle les 
ressources associees & la gestion de la connexion sont detruites. 

Lorsque le message regu, dans P6tat 314, est un message de 
demande de fin de connexion (message " release jreq" provenant du moyen de 
30 traitement du noeud source et message "release_cff\ en reponse), operation 
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318, le moyen de communication emet un message de relachement 255 
"release", operation 319, puis effectue les operations 320, 321 et 322. 

En ce qui concerne chaque noeud intermediaire (figure 5), apres 
avoir ete dans un etat d'initialisation 300, un message entrant 251 "set-up" est 
5 regu au cours d'une operation 331, de la part du noeud source (voir operation 
305). Le service requis pour la connexion consideree est alors extrait de ce 
message 251 "set-up". Le moyen de communication du noeud intermediaire 
effectue alors un calcul des parametres de transmission, a partir du service 
requis, puis, si la charge est acceptable, une mise a jour de ses tables de 
10 charge, au cours d'une operation 332, detaillee figure 14. 

Ensuite, au cours d'un test 335, le moyen de communication du 
noeud intermediaire determine si la bande passante necessaire a la connexion 
envisagee est disponible sur le chemin selectionne, ou non (voir test 304). 

Lorsque le resultat du test 335 est negatif, au cours d'une 
15 operation 333, le moyen de communication du noeud intermediaire emet un 
message de relachement de connexion "re/ease_jbac/c" a destination du noeud 
source (voir operation 310). Puis le moyen de communication du noeud 
intermediaire libere les ressources associees a la gestion de la connexion 
consideree, operation 334. 

20 Lorsque le resultat du test 335 est positif, au cours d'une operation 

336, le moyen de communication emet un message d'initialisation "set-up" 251 
a destination du moyen de communication du noeud destinataire et de chacun 
des moyens de communication des eventuels noeuds intermediates. Ce 
message est emis apres mise a jour du champ identifiant la position du noeud 

25 dans le chemin, a partir de la description du chemin en termes de liens (voir 
figure 9). 

Ensuite, au cours d'une operation 337, le compteur d'horloge 
"cncAckWaif est initialise & une valeur qui correspond a la duree maximale 
accordee a I'etablissement de la connexion. Le moyen de communication se 
30 met alors dans I'etat 338 d'attente de la reponse du reseau quant k 
I'etablissement de la connexion. 
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Dans cet etat 338, cinq evenernents differents peuvent se 
produire, au cours d'operations 339, 341, 345, 346 et 347. 

Lorsque le message entrant est un message "cncAckWaif, 
provenant du passage a zero de la valeur du compteur de signaux d'horloge 
5 "cncAckWaiF initialise au cours de I'operation 337, operation 339, le moyen de 
communication emet un message de relachernent "release", operation 340, a 
destination du noeud destinataire et des eventuels noeuds intermediates qui le 
separent du noeud destinataire, et emet un message de relachernent 
"release_back\ a destination du noeud source et des eventuels noeuds 
10 intermediaires qui le separent du noeud source, operation 342. Ensuite, au 
cours d'une operation 343, le moyen de communication du noeud intermediaire 
considere procede a la mise a jour des tables de charge associees a la 
connexion qui a ete rejetee. Puis, au cours d'une operation 344, les ressources 
associees a la gestion de la connexion sont liberees. 

15 Lorsque le message entrant est un message "release" 255, 

provenant du noeud source ou d'un noeud intermediaire entre le noeud source 
et le noeud intermediaire considere, operation 341, le moyen de communication 
effectue les operations 342 a 344. 

Lorsque, dans I'etat 338, le message entrant est un message 256 
20 "LinkTabFree", operation 347, ce message est memorise et le moyen de 
communication reste dans I'etat 338. 

Lorsque, dans I'etat 338, le message entrant est un message de 
demande de fin de connexion emis par un moyen de controle de noeud, dont la 
fonction est de prendre en compte les differents problemes du r6seau f 
25 operation 346, ce message est m6moris6 et le moyen de communication reste 
dans I'etat 338. 

Enfin, lorsque le message entrant est un message 253 
"LinkTabLoad", comportant notamment la description du service requis, ainsi 
que la description du chemin en termes de liens, en provenance du noeud 
30 source (voir operation 313), operation 345, le moyen de communication se met 
dans un etat 348 au cours duquel il attend une evolution de la connexion et 
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transmet toutes les donnees destinees a etre transmises en mode connecte, 
sur la connexion mise en place. 

On observe ici que le message 253 "LinkTabLoad" a, vis a vis 
d'un noeud intermediate (et du noeud destinataire), pour fonction de confirmer 
5 Petablissement de la connexion, au cours de Toperation 345. 

Dans I'etat 348, trois evenements peuvent se produire, au cours 
d'operations 349, 350 et 351. 

Lorsque, dans I'etat 348, le message entrant est un message 256 
"LinkTabFree", operation 351, ce message est memorise et le moyen de 
10 communication reste dans I'etat 348. 

Lorsque, dans I'etat 348, le message entrant est un message 255 
"re/ease", l'op§ration 353 decrite plus loin est effectuee. 

Enfin, lorsque, dans I'etat 348, le message entrant est un 
message de demande de fin de connexion, emis par un moyen de controle de 
15 noeud, operation 350, le moyen de communication emet un message de 
relachement n release_back?' a destination du noeud source, operation 352. 

A la suite de I'une des operations 349 ou 352, le moyen de 
communication effectue. au cours d'une operation 353, remission d'un message 
de relachement "release" a destination du noeud destinataire et de chaque 
20 eventuel noeud intermediaire qui separe le noeud intermediaire considere et le 
noeud destinataire. 

Le moyen de communication effectue alors une operation 354 
identique a Poperation 324, puis une operation 355 au cours de laquelle le 
compteur d'horloge "cnCiAcfcWa/f est initialise a une valeur qui correspond a la 
25 duree maximale accordee a la liberation de la connexion. Le moyen de 
communication se met alors dans I'etat 356 d'attente de la r6ponse du reseau 
quant au relachement de la connexion. 

Dans I'etat 356, deux messages peuvent survenir, au cours 
d'opferations 357 et 358. 
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Lorsque le message entrant est un message 256 "LinkTabFree", 
operation 357, les ressources associees a la gestion de la connexion sont 
Iib§rees, operation 360. 

Lorsque, dans I'etat 356, le message entrant est un message 
5 "cncAckWaif\ provenant du passage & zero de la valeur du compteur de 
signaux d'horloge "cncAckWaif initialise au cours de Toperation 355, operation 
358, le moyen de communication emet un message d'alarme "alarm_dcnTO % \ 
operation 359, a destination d'un moyen de controle de noeud, ce qui a pour 
effet de declencher le traitement d'une alarme par ce rnoyen de traiternent 
10 puisque la connexion n'a pas ete relachee de maniere normale. 

A la suite de Tune des operations 357 ou 359, les ressources 
associees a la gestion de la connexion sont liberees, operation 360. 

En ce qui concerne le noeud destinataire, (figure 6), apres avoir 
ete dans un etat d'initialisation 370, un message entrant "setUp_end" est regu 

15 au cours d'une operation 371, de la part du noeud source ou d'un noeud 
intermediate. Le moyen de communication du noeud destinataire effectue alors 
I'extraction du service requis, operation 371, puis le calcul des parametres de 
transmission a partir du service requis, et, si la charge est acceptable, la mise £ 
jour de la table de charge, au cours d'une operation 372 similaire a I'operation 

20 332, decrite figure 14. 

Ensuite, au cours d'un test 373, le moyen de communication du 
noeud destinataire determine si la bande passante necessaire a la connexion 
envisagee est disponible sur le chemin s6lectionne, ou non (voir tests 304 et 
335). 

25 Lorsque le resultat du test 373 est negatif, au cours d'une 

operation 333, le moyen de communication du noeud destinataire 6met, £ 
destination du noeud source et de tous les 6ventuels noeuds intermediates, un 
message de relachement n release_bacK\ au cours d'une operation 380. 
Ensuite, les ressources associees d la gestion de la connexion sont Iib6r6es, 

30 operation 382. 
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Lorsque le resultat du test 373 est positif, le moyen de 
communication du noeud destinataire emet, a destination du moyen de 
traitement du noeud destinataire un message de demande de connexion 
%% connect JndT, au cours d'une operation 374. 

5 Puis, le moyen de communication se met dans un etat 375 

d'attente de la reponse du moyen de traitement du noeud destinataire. 

Dans Petat 375, trois evenements peuvent survenir, au cours 
d'operations 376, 377 et 378. Lorsque le message entrant est un message de 
relachement "release", provenant du noeud source ou de Tun des noeuds 
10 intermediates, il est memorise au cours de I'operation 376. 

Lorsque, dans I'etat 375, le message entrant est une reponse 
defavorable n callReq_nack", correspondant a un message "connect__ans" 
n6gatif (figure 3), provenant du moyen de traitement du noeud destinataire, 
operation 378, au cours d'une operation 379, le moyen de communication du 
15 noeud destinataire procede a la mise a jour des tables de charge associees a la 
connexion qui a 6t§ rejet6e. Puis les operations 380 et 382 sont effectuees. 

Enfin, lorsque, dans I'etat 375, le message entrant est un 
message favorable "callReq_acK\ correspondant a un message "connect_ans" 
positif (figure 3), en provenance du moyen de traitement du noeud destinataire, 

20 operation 377, le moyen de communication emet un message 252 "connect, 
directement vers le noeud source, par mise en oeuvre du moyen de routage, au 
cours d'une operation 381 . Ensuite, au cours d'une operation 383, le compteur 
d'horloge "cncAckWaif est initialise a une valeur qui correspond a un delai 
maximum accorde £ Petablissement de la connexion demandee. Le moyen de 

25 communication se met alors dans l'6tat d'attente de la reponse du r6seau quant 
a l'6tablissement de la connexion, 6tat 384. 

Dans cet 6tat 384, cinq 6v§nements peuvent survenir au cours 
d'op6rations 385, 386, 387, 389 et 390. 

Lorsque le message entrant est un message de relachement 
30 "release", provenant du noeud source ou de Tun des noeuds intermediaires, ii 
est memorise au cours de Toperation 385. 
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Lorsque, dans Tetat 384, le message entrant est un message de 
mise a jour de table de charge 256 "LinkTabFree", provenant du noeud source, 
il est memorise au cours de Toperation 389. 

Lorsque, dans Tetat 384, le message entrant est un message de 
5 demande de fin de connexion provenant du moyen de traitement ou d'un 
moyen de controle de noeud, il est memorise au cours de Toperation 386. 

Lorsque, dans Tetat 384, le message entrant est un message 
"cncAckWaif, provenant du passage a z6ro de la valeur du compteur de 
signaux d'horloge "cncAckWaif initialise au cours de I'operation 383, operation 
10 390, le moyen de communication emet un message de relachement de 
connexion n release_back\ operation 391, a destination des noeuds 
intermediates et du noeud source. 

Ensuite, au cours d'une operation 392, le moyen de 
communication du noeud destinataire procede a la mise a jour des tables de 
15 charge associees a la connexion qui a ete rejetee. Puis, au cours d'une 
operation 393, les ressources associees a la gestion de la connexion sont 
liberees. 

Enfin, lorsque, dans Tetat 384, le message entrant est un 
message 253 "LinkTabLoad", message comportant notamment la description 
20 du service requis ainsi que la description du chemin en terme de liens 
(message ayant pour fonction de confirmer Tetablissement de la connexion), 
operation 387, le moyen de communication du noeud destinataire se met dans 
un etat 388 d'attente devolution de la connexion. 

On observe ici que le message 253 "LinkTabLoad" a, vis a vis 
25 d'un noeud intermediate, pour fonction de confirmer Tetablissement de la 
connexion. 

Dans Tetat 388, trois evenements peuvent survenir, au cours 
d'operations 394, 396 et 397. 
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Lorsque, dans Petat 388, le message entrant est un message de 
mise a jour de table de charge 256 "LinkTabFree", provenant du noeud source, 
il est memorise au cours de I'operation 396. 

Lorsque, dans Petat 388, le message entrant est un message de 
5 relachement 255 "release", operation 397, le moyen de communication effectue 
la notification "callTerminate", correspondant a un message "release_ind" 
(figure 3), de la rupture de la connexion au moyen de traitement du noeud 
destinataire, operation 398. Ensuite, I'operation 399 decrite plus loin est 
effectuee. 

10 Enfin, lorsque, dans Petat 388, le message entrant est un 

message de demande de fin de connexion emis par un moyen de controle de 
noeud, operation 394, le moyen de communication emet un message de 
relachement " release JbacK* a destination du noeud source et des noeuds 
intermediates, operation 395. 

15 A la suite de Pune des operations 395 ou 398, le moyen de 

communication effectue une operation 399 identique a I'operation 324, puis une 
operation 400 au cours de laquelle le compteur d'horloge "cncAckWaif est 
initialise a une valeur qui correspond a la duree maximale accordee a la 
liberation de la connexion. Le moyen de communication se met alors dans Petat 

20 401 d'attente de la reponse du reseau quant au relachement de la connexion 
de la meme fa$on que pour les noeuds intermediaires. 

Dans Petat 401, deux messages peuvent survenir, au cours 
d'operations 402 et 403. 

Lorsque le message entrant est un message 256 "LinkTabFree", 
25 operation 402, les ressources associees & la gestion de la connexion sont 
Iib6r6es, operation 405. 

Lorsque, dans l'6tat 401, le message entrant est un message 
"cncAckWaif, provenant du passage £ z6ro de la valeur du compteur de 
signaux d'horloge n cna4c/cM/a/f initialise au cours de Pop6ration 400, operation 
30 403, le moyen de communication emet un message d'alarme " alarm jdcnTO", 
operation 404, a destination du moyen de controle de noeud, ce qui a pour effet 
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de declencher le traitement d'une alarme par ce moyen de traitement puisque la 
connexion n'a pas ete relachee de maniere normale. 

A la suite de Tune des operations 402 ou 404, les ressources 
associees a la gestion de la connexion sont liberees, operation 405. 

5 En ce qui concerne chaque noeud voisin (figure 7), apres avoir ete 

dans un etat d'initialisation 411, le moyen de communication du noeud voisin 
regoit un message 253 "LinkTabLoad", comprenant notamment la description 
du service requis ainsi que la description du chemin en termes de liens, 
operation 412. Ensuite, au cours d'une operation 413, le moyen de 
10 communication du noeud voisin effectue le calcul des parametres de 
transmission a partir du service requis, puis, independamment de la charge, la 
mise a jour de la table de charge. 

Ensuite, dans l'6tat 414, le moyen de communication du noeud 
voisin attend revolution de la connexion. Ensuite, au cours d'une operation 415, 
15 il regoit un message 256 "LinkTabFree" concernant la connexion, message 
comprenant notamment la description du service requis ainsi que la description 
du chemin en termes de liens. 

Ensuite, au cours d'une operation 416, le moyen de 
communication du noeud voisin precede a la mise a jour des tables de charge 
20 associees a la connexion qui a ete liberee. Puis, au cours d'une operation 417, 
les ressources associees a la gestion de la connexion sont liberees. 

On observe ici que le message 253 "LinkTabLoad" a, vis a vis 
d'un noeud voisin, pour fonction d'informer sur I'etablissement de la connexion. 

Ainsi la procedure (figure 7) correspond plutot a une notification 
25 qu'a un controle d'admission. 

En figure 8 sont representes, dans un reseau a commutation de 
paquets 800 : 

- un noeud source 801, 

- un noeud destinataire 802, 

30 - deux noeuds interm6diaires 803 et 804, 





- cinq noeuds voisins 805 a 809, et 

- les liens entre ces noeuds. 

Le long de ces liens sont representes des messages transitant 



successivement sur le reseau ainsi constitue, sous forme de Heches. 
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On observe que le message 251 "set-up" circule : 

- du noeud source 801 au noeud intermediaire 803, puis 

- du noeud intermediaire 803 au noeud intermediaire 804, puis 

- du noeud intermediaire 804 au noeud destinataire 802. 



En revanche, le message 252 "connect' retourne directement du 



10 noeud destinataire 802 au noeud source 801, sans intervention des noeuds 
intermediates 803 ou 804. Ce message 252 peut, en fait, passer par n'importe 
quel chemin entre le noeud destinataire et le noeud source, par exemple par un 
chemin passant par le noeud voisin 808. 



15 "LinkTabLoad" et 256 "LinkTabFree" sont diffuses a tous les noeuds du reseau, 
en suivant un arbre de recouvrement. 



recouvrement se trouvent sur le chemin de la connexion. Ainsi, lorsqu'il y a une 
panne dans le reseau, les noeuds du chemin, noeuds intermediates ou noeud 
20 destinataire, qui, comme on Pa vu dans les organigrammes des figures 5 et 6, 
attendent le message "LinkTabLoad" 253, respectivement dans les etats 345 et 
387, peuvent detecter la panne lorsque Tun des noeuds voisins ne transmet pas 
ce message. 



25 structures des messages 251 "set-up", 255 "release", de mise a jour de table de 
charge, 253 "LinkTabLoad" ou 256 "LinkTabFree" et 252 "connect. 



Enfin, les messages de mise a jour de table de charge 253 



Preferentiellement, toutes les extremites, ou "feuilles" de Parbre de 



En figure 9, on observe, sur quatre lignes successives, les 



Le message 251 "set-up n comporte successivement les champs : 
901, d'identification du type de message ("set-up", 
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"LinkTabLoad 9 , "LinkTabFree", "Connect 1 ou "Release", voir figure 3), 
- 902, d'identification de connexion, 
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- 903, de description de trafic, representatif du service requis, 

- 904, de donnees propres au moyen de communication 
permettant notamment d'identifier les moyens de traitement des noeuds source 
et destinataire, 

5 - 905, de nombre de liens qui utilisent le cherhin associe a la 

connexion, 

- 906, de rang du lien sur lequel transite le message, sur le chemin 
associe a la connexion, 

- 907, des descripteurs de liens successifs du chemin 
10 correspondant a la connexion souhaitee, et 

- 908, de donnees de protocole. 

Le message 255 "re/ease" comporte successivement les 

champs : 

- 901, d'identification du type de message ("set-up" t 
1 5 "LinkTabLoad", "LinkTabFree", "Connect' ou "Release", voir figure 3), 

- 902, d'identification de connexion, 

- 909, de cause de la demande de relachement, 

- 905, de nombre de liens qui utilisent le chemin associe a la 

connexion, 

20 - 906, de rang du lien sur lequel transite le message, sur le 

chemin associe a la connexion, 

- 907, des descripteurs de liens successifs du chemin 
correspondant a la connexion souhaitee, et 

- 908, de donnees de protocole. 

25 Un message de mise a jour de table de charge 253 ou 256 

comporte successivement les champs : 

- 901, d'identification du type de message ("set-up'\ 
"UnkTabLoad\ "LinkTabFree", "Connect' ou "Release", voir figure 3), 

- 902, d'identification de connexion, 

30 - 903, de description de trafic, representatif du service requis, 
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- 910, d'information relative a Parbre de recouvrement mis en 

oeuvre, 

- 905, de nombre de liens qui utilisent le chemin associe a la 

connexion, 

5 - 906, de rang du lien sur lequel transite le message, sur le chemin 

associe a la connexion, 

- 907, des descripteurs de liens successifs du chemin 
correspondant a la connexion souhaitee, et 

- 908, de donnees de protocole. 

10 Le message 252 "connect 9 comporte successivement les 

champs : 

- 901, d'identification du type de message ("sef-up", 
"LinkTabLoacT, "LinkTabFree", "Connect ou "Release", voir figure 3), 

- 902, d'identification de connexion, 

15 - 911, de donnees de protocole, pouvant etre utilisees par le 

moyen de traitement du noeud source. 

- 908, de donnees de protocole. 

En figure 10, on observe des descripteurs de liens 1001 a 1007 
disposes cote a cote et des descripteurs de chemins 101 1 a 1015 disposes sur 
20 des lignes successives. 

Chaque descripteur de chemin est une structure de donn6es pour 
la description d'un chemin qui comporte, en particulier la reference des liens 
impliques dans la description de ce chemin et la reference de chaque 
connexion associee a ce chemin. Chaque descripteur de chemin sortant (101 1, 
25 1012 ou 1013) concerne un chemin cre6 par le moyen de routage du moyen de 
communication. 

Les chemins qui ne partent pas du noeud consid6r6 sont dits 
"temporaires" et permettent de connattre les charges des liens des chemins 
sortants. Les chemins temporaires sont cr§6s par le moyen de controle de 
30 charge qui gere tous les chemins (operations 1307, 1407 et 1504, figures 13 a 
15). 




35 



Dans le mode de realisation decrit et represents, les chemins 
1011, 1012 et 1013 sont des chemins sortants (en traits gras) et les chemins 
1014 et 1015 sont des chemins temporaires (en traits fins). Les chemins 1011, 
1012 et 1013 decrivent la table de routage et sont utilises par le noeud 
5 considere pour etablir des chemins vers n'importe quel noeud destinataire. 

Chaque descripteur de lien 1001 a 1007 comporte, en particulier, 
la reference de chaque chemin qui traverse le lien considere, identify par un 
rectangle, a Intersection d'une ligne verticale partant du descripteur de lien 
considere et d'une ligne horizontale partant du descripteur de chemin 
10 considere. 

Les liens 1001 a 1004 font partie d'au moins Tun des chemins 
sortants, et sont representes en traits gras. Chaque intersection de deux lignes 
marquee par un point represente une reference en mSmoire : 

- les lignes externes (en haut et/ou a gauche des rectangles) 
15 reperent les references conservees avec chaque lien : ces references 

concernent chaque chemin qui traverse ledit lien, et 

- les lignes internes (en bas et/ou a droite des rectangles) reperent 
les references conservees avec chaque chemin : ces references concernent 
chaque lien traverse par ledit chemin. 

20 La mise a jour de la table de charge effectuee par le moyen de 

controle de charge, comporte les etapes suivantes : 

- pour I'etablissement d'une connexion : 

• mise a jour de la charge de tous les liens references par 
le chemin (ajout de charge), et 

25 • pour chaque lien, mise a jour de la charge de chaque 

chemin reference pour ce lien ; 

- pour le retrait d'une connexion : 

• mise a jour de la charge de tous les liens r6ferenc6s par 
le chemin (deduction de charge), et 

30 • pour chaque lien, mise a jour de la charge de chaque 

chemin reference pour ce lien ; 
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- pour I'ajout d'un chemin : 

• soit par le moyen de routage, lors de I'etablissement de 
la table de routage du noeud considere (il s'agit alors 
d'un chemin sortant), ou lors de la mise a jour de la table 
de routage, 

• soit par le moyen de controle de charge, lorsque le 
chemin associe a une nouvelle connexion lors de I'ajout 
de charge n'est pas deja specifie (il s'agit alors de 
chemin temporaire) ; 

- pour la suppression d'un chemin : 

• par retrait d'un chemin temporaire lorsqu'il n'est plus 
traverse par aucune connexion, apres retrait d'une 
connexion, soit lorsque la liste de connexions ref6rencee 
par ce chemin est vide, 

- pour la transformation d'un chemin sortant en chemin temporaire 
lorsqu'il ne fait plus partie de la table de routage (a la suite d'une operation de 
mise a jour de la table de routage) ; et 

- pour la suppression d'un lien : 

• par retrait d'un lien lorsqu'il n'est plus traverse par aucun 
chemin, ou lorsque la liste des chemins references par 
ledit lien est vide. 

Dans la table de charge, a chaque lien est associee une 
information de charge et a chaque chemin est associee une information 
representative du lien le moins disponible. Ainsi, la bande passante disponible 
du lien le moins disponible est aussi la bande passante disponible du chemin. 

On observe que c'est en utilisant cette information de disponibilite 
de bande passante de chemin, que le moyen de communication effectue le 
choix du chemin en choisissant le chemin le plus disponible. Pour chaque 
information a transmettre en mode non connecte, la disponibilite de chaque 
chemin du reseau est ainsi estimee, en fonction du trafic en mode connecte. 

La charge d'un chemin est definie a partir de son lien le moins 
disponible. II est caracterise par la bande passante totale qu'il autorise et la part 
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maximale de la bande passante associ6e au trafic en mode connecte. Etant 
donnee la charge effective du trafic en mode connecte, chaque moyen de 
communication definit la part associee au trafic en mode non connecte, comme 
egale a la bande passante totale a laquelle on a soustrait la part associee au 
5 mode connecte. 

Le moyen de communication alloue a I'ensemble des 
transmissions en mode non connects qu'il a a effectuer, tout ou partie de la 
bande passante (preferentiellement une partie, pour eviter des problemes de 
congestion du reseau). Cette part est equitablement repartie entre toutes les 
10 transmissions en mode non connecte et se trouve done dynamiquement mise a 
jour au debut et a la fin de chaque transmission en mode connecte (lorsque la 
charge du trafic en mode connecte varie). 

^attribution d'une part est effectuee en definissant un plage de 
valeurs du nombre de paquets a emettre entre deux valeurs extremes 
15 {spec__CPmin 1114 et spec_CPmax 1115 (figure 11). Cette operation 
d'attribution de bande passante est effectuee avant remission de reformation 
257 ou 259 (figure 3). 

En outre, on considere qu'un chemin qui supporte plus d'un 
nombre predetermine de transmission sortante en mode non connecte n'est 
20 pas disponible pour une transmission en mode non connecte supptementaire. 

Les evenements qui peuvent influencer Tattribution de bande 
passante a une transmission en mode connecte sont de deux types : 

- ceux qui concernent le mode connecte, I'etablissement ou la 
fermeture d'une connexion, et qui influent sur la bande passante qui lui est 

25 reservee, et, par consequent, sur le nombre de paquets a 6mettre en mode non 
connecte mais aussi sur la taille de ces paquets, et 

- ceux qui concernent le mode non connecte, le d6but ou la fin 
d'une transmission, et qui influent sur le nombre de paquets a emettre en mode 
non connecte. 

30 Pour la gestion de la table de charge illustr§e en figure 10, la 

charge d'un chemin est d6termin6e par la charge du lien le moins disponible, en 
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prenant en cornpte, pour la charge d'un lien, la somme des charges des 
chemins qui le traversent. 

Les chemins sortants utilises sont etablis par un moyen de 
routage de type connu. 

On observe ici que chaque noeud du reseau controle le flux qu'il 
genere et que reformation permettant de controler ces flux est etablie a partir 
de la table de charge qui est partagee entre les differents noeuds, chaque 
noeud conservant cette information sous forme d'un tableau tel que celui illustre 
en figure 11. 

Les niveaux de priorite des messages sont etablis par le moyen 
de traitement a partir du service requis. 

En figure 11, on observe un tableau 1100, comportant trois lignes 
1101, 1102 et 1103, chacune des lignes comportant des specifications de 
canaux virtuels 1 105 a 1 1 10. 

On rappelle ici que chaque canal virtuel est une entite logique 
associee a une communication entre deux applications mises en oeuvre par 
deux moyens de traitements associes a deux moyens de communication. 

Dans le tableau de la figure 11, on a choisi de representer deux 
canaux virtuels pour chaque niveau de priorite, pour des raisons de clarte. 
Cependant, pour chaque niveau de priorite, le nombre de canaux virtuels peut 
varier entre zero a un nombre predetermine. 

Chacune de ces specifications comporte : 

- une information representative de la taille "spec_L" 1111 des 
paquets associes au canal ; 

- une information repr6sentative du nombre de paquets a 6mettre 
n spec__CP" 1112 durant I'intervalle de temps primaire consid6r6 ; 

- une information repr6sentative de la dur6e n spec_CV 1113 de 
I'intervalle de temps primaire consid6re ; 

- une information representative du niveau de priorite (haut, 
moyen ou bas) "spec _prio" 1114 associe au canal ; 
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- une information "dyn_CP f 1117 representative du nombre de 
paquets r6ellement emis sur le canal virtuel, pendant I'intervalle de temps 
primaire consid6re ; 

- une information "dyn_CT 1118 representative du nombre 
5 d'intervalles de temps secondaires 6coules pendant Pintefvalle de temps 

primaire considere ; et 

- une information "VC_state" 1119 representative de l'6tat dans 
lequel se trouve le canal virtuel, "libre'\ "actif ou "endormr (voir figure 12) ; et 

- une information "references" 1120 representative des positions 
10 (ou references), en memoire, des donnees utilisateur a transmettre. 

En outre, les specifications du niveau de priorite basse 

comportent : 

- une information "spec_CPmin" 1115 representative de la valeur 
minimale du nombre de paquets a emettre "spec_CP* 1112 - une information 

15 "spec^CPmatf* 1116 representative de la valeur maximale du nombre de 
paquets a emettre "spec_CP % 1112 , ceci afin de permettre de diminuer la 
valeur de "spec^CP* 1112 au cours de l'op6ration 1221 ou de I'augmenter au 
cours de Poperation 1215, dans la limite de ces bornes spec_CPmin 1115 et 
specjCPmax 1116. 

20 Enfin, chaque ligne, ou niveau de priorite, est affectee d'une 

information "prio_state" 1120 representative de I'etat dans lequel se trouve 
Pensemble des canaux virtuels du niveau de priorite consider^ : lorsqu'au 
niveau de priorite consider^ ne se trouve aucun canal, le niveau de priorite est 
"libre", lorsque tous les canaux du niveau de priorite sont dans un 6tat 

25 "endormr, le niveau de priorite est lui-meme dans un etat "endormf\ et dans les 
autres cas, le niveau de priorite est "actif 1 . 

La table de specifications et de priorites 1100 est constitute en 

plagant : 

- en premiere ligne 1101 (niveau de priorite "haut") tous les 
30 canaux virtuels affectes a des transmissions en mode connecte, ou "temps r6el 

deterministe" (en anglais "predictive real time") ; 
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- en deuxieme ligne 1102 (niveau de priorite "moyen") tous les 
canaux virtuels affectes a des transmissions en mode connecte temps reel 
garanti (connu sous le nom de temps reel garanti, ou , en anglais, "guaranted 
real time") ; 

5 - en troisieme ligne 1103 (niveau de priorite "haut") tous les 

canaux virtuels affectes a des transmissions en mode non connecte (connu 
sous les noms de "asynchrone" et "elastique", ou , en anglais "elastic"). 

Ainsi, tous les noeuds disposent d'une table de priorite concernant 
le trafic qu'il peut generer, et chacun s'occupe des messages dont il est la 
10 source (principe connu sous le nom de "outgoing trafic" en anglais, qui signifie 
"trafic sortant"). 

On observe ici que les parametres de transmission sont 
determines par le moyen de controle de charge a partir du contenu de la table 
de charge. Par consequent, les parametres de transmission associes aux 
15 canaux virtuels de haute et moyenne priorite 1 101 et 1 102 sont calcules a partir 
d'une connaissance, a priori, sur tout le trafic connecte alors que les 
parametres de transmission associes aux canaux virtuels de faible priorite 1 103 
sont estimes a partir d'une connaissance limitee au trafic non-connect6 sortant 
du noeud considere. 

20 La figure 12 represente un organigramme de fonctionnement 

d'emission en modes connecte et non connecte d'un moyen de communication 
tel qu'illustre en figure 2. Cet organigramme est mis en oeuvre par I'unite 
centrale 206 (figure 2). 

Le principe du fonctionnement utilise est que Tordre d'emission 
25 des paquets est bas6 sur le remplissage d'un intervalle de temps primaire IT-P, 
comprenant des intervalles de temps secondares IT-S. 

A la suite de l'op6ration d'initialisation 1201 par remise £ z6ro de 
toutes les variables, un test 1202 determine si un intervalle de temps 
secondaire s'est ecoul6 f le d6but d'un intervalle de temps secondaire 6tant 
30 determine a partir de Thorloge temps reel 235. Lorsque le resultat du test 1202 
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est positif, au cours d'une operation 1203, I'unite centrale 206 se place en d6but 
de la table de specifications et de priorites (figure 11). 

Ensuite, au cours d'une operation 1204, reformation "dynjCT 
1 1 18 du canal virtuel considere est d§crementee. Puis, au cours d'un test 1205, 
I'unite centrale 206 determine si la valeur de rinformation "dyn_CT 1118 du 
canal virtuel considere est egale a zero, ou non. Lorsque le resultat du test 
1205 est positif, c'est-a-dire a la fin d'un intervalle de temps primaire, au cours 
d'un test 1220, I'unite centrale 206 determine si la valeur de ('information 
"dynJDR* 1117 est egale a zero, ou non. Le test 1220 correspond done a 
chaque d6but d'un nouvel intervalle de temps primaire. 

Lorsque le resultat du test 1220 est negatif, au cours d'une 
operation 1221 , I'unite centrale 206 gere les priorites de la maniere suivante : 

- pour le trafic deterministe, priorite haute, les paquets non 
transmis durant Tintervalle de temps requis, dont le nombre est egale a la 
valeur de valeur "dyn_CP" 1117, sont supprimes (perte de paquets) puis, la 
valeur "dynjCR* 1 1 17 est mise a zero , et 

- pour le trafic garanti, priorite moyenne, les paquets non transmis 
durant Tintervalle de temps sont conserves et "dyn_CP % 1117 conserve sa 
valeur, et 

- pour le trafic elastique, priorite basse, la bande passante est 
reduite, par decrementation de la valeur "spec_CR' 1112 dans la limite des 
bornes autorisees. 

A la suite de I'operation 1221 ou lorsque le resultat du test 1220 
est positif, une operation 1206 est effectu6e. 

Au cours de I'operation 1206, les specifications et param^tres de 
transmission sont mis £ jour (voir figure 11): 

- les informations 1111 d 1113 et 1115 d 1116 sont mises § jour £ 
la fin de chaque intervalle de temps primaire, en fonction des changements 
d'6tat de la table de charge determine par le moyen de controle de charge, 

- la valeur de rinformation "dyn_CP" 1117 est incr6ment6e de la 
valeur de rinformation "spec_CR 9 1112, 
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- la valeur de reformation "dyn_CV 1118 est incrernentee de la 
valeur de Pinformation "spec_CT 9 1113, 

- la valeur de I'information "VC_state" 1119 passe de I'etat 
"endormr a Tetat "actiT. 

5 A la suite de I'operation 1206 ou lorsque le resultat du test 1205 

est negatif, une operation 1207 consiste, pour I'unite centrale 206, a considerer 
le canal virtuel suivant dans la table de specifications et de priorites. 

Ensuite, le test 1208 determine si la fin de la table de 
specifications et de priorites a ete depassee, ou non. Lorsque le resultat du test 

10 1208 est n6gatif, les operations 1204 a 1207 sont reiterees. Lorsque le resultat 
du test 1208 est positif, c'est-a-dire lorsqu'un intervalle de temps secondaire est 
acheve, un test 1209 determine si la liste des canaux virtuels de niveau de 
priorite "hauT possede une information d'etat "prio_state" 1120 a la valeur 
"acf/7" ou non. Lorsque le resultat du test 1209 est positif, au cours d'une 

15 operation 1210, I'unite centrale 206 procede a remission du paquet dont le 
remplissage est effectue a partir du champ reference 1120, qui indique la 
position memoire des prochaines donnees a emettre, en mode connects temps 
reel deterministe et procede a la rnise a jour des specifications du canal virtuel 
permettant remission du paquet considere : 

20 - I'information "dyn_CP» 1 1 1 7 est decrementee, 

- si reformation "dyn^CP 1 1117 est egale a zero, la valeur de 
I'information n VC_state" 1119 prend la valeur "endormr et le prochain canal 
virtuel du meme niveau de priorite est considere et, s'il n'y a aucun autre canal 
virtuel de meme niveau de priorite, le niveau de priorite voit son information 

25 "prio_state tt 1 120 prendre la valeur "endormF\ 

L'6mission du paquet ne se termine que lorsque le prochain noeud 
interm6diaire a acquitte le controle de flux qu'il a oper6 sur les donn6es dudit 
paquet, tel que cela est d6crit dans la norrne IEEE-1355 et implements par les 
composants ST-C101 213 ou 216 et ST-C104 209. 

30 On remarque ainsi que les conflits d'acces aux ressources de 

transmission (les liens de communications) sont detectes par le protocole de 
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transmission de paquets, par exemple conforme a la norme IEEE-1355. 
^invention perrnet done de limiter les effets de ces conflits d'acces pour 
equitablement repartir I'acces aux ressources entre les differents noeuds du 
reseau, tout en garantissant une qualite de service specifiee par le service 
5 requis. 

Lorsque le resultat du test 1209 est negatif, un test 1211 
determine si la liste des canaux virtuels de niveau de priorite "rnoyen" poss^de 
une information d'etat "prio_state" 1120 a la valeur "acf/f ou non. Lorsque le 
resultat du test 1211 est positif, au cours d'une operation 1212, I'unite centrale 
10 206 procede a remission d'un paquet en mode connecte temps reel garanti et 
procede a la mise a jour des specifications du canal virtuel permettant 
remission du paquet considere : 

- reformation "dyn_CR* 1 1 1 7 est decrementee, 

- si reformation n dyn_CP' 1117 est egale a zero, la valeur de 
15 reformation v VC_state" 1119 prend la valeur "endormf et le prochain canal 

virtuel du meme niveau de priorite est considere et, s'ii n'y a aucun autre canal 
virtuel de meme niveau de priorite, le niveau de priorite voit son information 
"prio_state" 1 120 prendre la valeur "endormr. 

Lorsque le resultat du test 1211 est negatif, un test 1213 

20 determine si la liste des canaux virtuels de niveau de priorite "bas" possede une 
information d'etat "prio_state" 1120 a la valeur "actff ou non. Lorsque le resultat 
du test 1213 est positif, au cours d'une operation 1214, I'unite centrale 206 
procede & remission d'un paquet en mode non connecte et procede a la mise a 
jour des specifications du canal virtuel permettant remission du paquet 

25 considere : 

- 1' information "dyn_CP" 1117 est d6cr6mentee, 

- si reformation "dyn_CP % 1117 est egale a z6ro, la valeur de 
reformation "VC_state" 1119 prend la valeur "endormF et le prochain canal 
virtuel du meme niveau de priorite est consider^ et, s'il n'y a aucun autre canal 

30 virtuel de meme niveau de priorite, le niveau de priorite voit son information 
"prio_state" 1120 prendre la valeur "endormi". 
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Lorsque le r6sultat du test 1213 est negatif, au cours d'une 
operation 1215, I'unit6 centrale procede a I'analyse de la charge effective du 
reseau. A cet effet, I'unite centrale 206 cornptabilise les periodes d'inactivite du 
moyen de communication, pour ajuster le nombre de paquets a emettre par 
5 canal virtuel, pour le trafic de priorite basse (c'est-a-dire en mode non 
connecte). 

En fonction du nombre d'intervalles de temps secondaires non 
utilises pour la transmission effective de paquets, la bande passante est accrue, 
par incrementation de la valeur "spec_CP" 1112 dans la limite des bornes 
10 autorisees. 

Puis, le moyen de communication cesse ses emissions jusqu'a ce 
que le resultat du test 1202 devienne positif. 

^allocation ou la liberation d'un canal virtuel est effectuee par 

manipulation: 

15 - des listes 1101 et 1102, lors de I'execution des differentes 

etapes de gestion d'une connexion illustree en figure 4. 

- de la liste 1103, lors de la reception d'un message 
"SendSyncData_req" ou "SendAsyncDatajctf\ par le moyen de 
communication, emis par le moyen de traitement, jusqu'a transmission 
20 complete du message. 

Ainsi, le moyen de controle de charge tient compte de la charge 
effective sur le reseau pour repartir les droits d'acces entre les differents 
niveaux de priorite. 

La figure 13 represente un organigramme de determination, par le 
25 noeud source, de disponibilit6 de chemin pour I'etablissement d'une connexion, 
ce qui correspond, en figure 4, & l'op6ration 302. 

Le moyen de communication prend en compte la description du 
service requis etabli par I'application ou le p6ripherique qui emet le message, 
au cours d'une operation 1302. 
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Puis, le moyen de communication effectue le choix du canal virtuel 
et du chemin le plus disponible, au cours de Poperation 1304, en faisant usage 
de la table de routage. 

Au cours d'un test 1305, le moyen de communication du noeud 
5 source determine si un chemin a ete choisi au cours de I'operation 1304 ou 
non. 

Lorsque le resultat du test 1305 est negatif, le moyen de 
communication revendique I'arret de la procedure de mise en place de la 
connexion, au cours d'une operation 1306. Lorsque le resultat du test 1305 est 
10 positif, le moyen de communication effectue le calcul des parametres de 
transmission, en particulier de la bande passante, de la taille des paquets 
transmis, des taux (frequences d'emission) de paquets et de priorite de la 
communication correspondant au champ 1111 a 1113 illustres en figure 11, en 
faisant usage de la table de charge, au cours d'une operation 1303. 

15 Puis, au cours d'une operation 1307, le moyen de communication : 

- alloue un canal virtuel en specifiant les parametres de 
transmission precedemment calcules, et 

- fait varier la taille des paquets avec la charge du chemin ainsi 
que le taux de paquets sur ledit chemin, et 

20 - met a jour sa table de charge par I'interrnediaire du moyen de 

controle de charge. 

Ensuite, au cours d'une operation 1308, il revendique la poursuite 
de la mise en place de la connexion 

L'operation 302 est alors terminee. 
25 La figure 14 represente un organigramme de determination, par 

un noeud intermediate ou le noeud destinataire, de disponibilite de chemin 
pour I'etablissement d'une connexion, ce qui correspond, en figures 5 et 6, aux 
operations 332 et 372. 

Le moyen de communication obtient, d'abord, la description du 
30 chemin et du service requis assoctes a la nouvelle connexion, en lisant le 
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message 251 "sef-up" provenant du noeud source (operation 305), au cours 
d'une operation 1402. 

Puis, le moyen de communication verifie la disponibilite du chemin 
en fonction du service requis, au cours de I'operation 1404, en faisant usage de 
5 la table de routage. 

Au cours d'un test 1405, le moyen de communication du noeud 
considere determine si le chemin est disponible au cours de I'operation 1404 ou 
non. 

Lorsque le resultat du test 1405 est negatif, le moyen de 
10 communication revendique la procedure de mise en place de la connexion, au 
cours d'une operation 1406. Lorsque le resultat du test 1405 est positif, le 
moyen de communication effectue le calcul des parametres de transmission, en 
particulier de la bande passante, de la taille des paquets transmis, des taux 
(frequence d'emission) de paquet et de priorite de la communication, en faisant 
15 usage de la table de charge, au cours d'une operation 1403. 

Puis, au cours d'une operation 1407, le moyen de communication 
met & jour sa table de charge par I'intermediaire du moyen de controle de 
charge, ce qui revient a reserver les ressources necessaires a la connexion 
envisagee, puis, au cours d'une operation 1408, il poursuit la mise en place de 
20 la connexion. A la fin de Tune des operations 1406 ou 1408, I'operation 334 est 
terminee. 

La mise a jour de la table de charge s'accompagne d'une mise a 
jour des parametres de transmissions associes aux canaux virtuels existants 
representatifs du trafic sortant pour le noeud considere, a travers la valeur des 
25 champs 1111 & 1113 pour le trafic connecte et 1111, 1113, 1115, 1116 pour le 
trafic non connecte. 

La figure 15 represente un organigramme de determination, par 
un noeud voisin, de disponibilite de chemin pour l'6tablissement d'une 
connexion, ce qui correspond, en figure 7, aux operations 413. 




• 
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Le moyen de communication obtient, d'abord, la description du 



chemin et du service requis associes a la nouvelle connexion, en lisant le 
message 253 "LinkTabLoad" provenant du noeud source (operation 313), au 
cours d'une operation 1502. 



parametres de transmission, en particulier de la bande passante, de la taille des 
paquets transmis, des taux de paquet et de priorite de la communication, en 
faisant usage de la table de charge, au cours d'une operation 1503. Puis, au 
cours d'une operation 1504, le moyen de communication met a jour sa table de 
10 charge. A la fin de Poperation 1504, le fonctionnement de mise en place de la 
connexion, par le noeud voisin, est termine. 
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Ensuite, le moyen de communication effectue le choix des 
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REVENDICATIONS 

1. Procede de communication entre des dispositifs de 
communication (101 £ 105, 801 a 809) d'un reseau a commutation de paquets 
comportant au moins un commutateur (209), caracterise en ce qu'il comporte 
une operation de determination de mode de transmission (1302), au cours de 
laquelle, pour chaque information a transmettre, on determine un mode de 
transmission, connecte ou non, puis 

- pour chaque information a transmettre en mode connecte : 

• une operation de reservation de chemin (1304 a 1308, 
301 a 313) sur ledit reseau, puis 

• une operation de transmission de ladite information 
(314), en mode connecte, sur le chemin reserve au cours 
de Toperation de reservation, et 

- pour chaque information a transmettre en mode non connecte : 

• une operation d'estimation de disponibilite de chemin sur 
ledit reseau, puis, lorsqu'un chemin est estirne disponible 
pour la transmission de ladite information, 

• une operation de transmission de ladite information, sur 
ledit chemin, en mode non connecte. 

2. Procede de communication selon la revendication 1, caracterise 
en ce que, Toperation de reservation de chemin comporte une operation de 
transmission (305), sur ledit chemin, d'un message (251) comportant des 
informations representatives du service requis pour la transmission en mode 
connect6. 

3. Proced§ de communication selon Tune quelconque des 
revendications 1 ou 2, caracteris6 en ce que Top6ration de reservation de 
chemin sur ledit reseau, comporte une operation de mise a jour (1303, 1307, 
1403, 1407, 1503, 1504) d'une table de charge (1100) conservee par chaque 
dispositif de communication du reseau. 

4. Proced6 de communication selon la revendication 3, caract6ris§ 
en ce que, au cours de Toperation d'estimation de disponibilite, on prend en 




compte des valeurs conservees dans la table de charge (1100) du dispositif de 
communication qui a au moins une information a transmettre. 

5. Precede de communication selon Tune quelconque des 
revendications 3 ou 4, caracterise en ce que I'operation de mise a jour de table 

5 comporte une operation de determination de parametres (1303, 1403, 1503) 
representatifs du service requis pour la transmission en mode connects. 

6. Procede de communication selon Tune quelconque des 
revendications 3 a 5, caracterise en ce que I'operation de mise a jour de table 
de charge comporte une operation de mise en memoire de la bande passante 

10 disponible pour chaque lien (1001 a 1004) d'un chemin sortant du dispositif de 
communication considere (1011 a 1013). 

7. Procede de communication selon Tune quelconque des 
revendications 3 a 6, caracterise en ce que ['operation de mise a jour de table 
de charge comporte une operation de mise en memoire de la bande passante 

15 disponible pour chaque lien (1001 a 1007) du reseau faisant partie d'un chemin 
associe a une connexion (1011 a 1015). 

8. Procede de communication selon Tune quelconque des 
revendications 1 a 7, caracterise en ce que, I'operation de reservation de 
chemin comporte une operation de verification (1404, 1405), par chaque 

20 dispositif de communication intermediate (803, 804) sur ledit chemin, de la 
disponibilite du chemin a reserver. 

9. Procede de communication selon Tune quelconque des 
revendications 1 a 8, caracterise en ce que I'operation d'estimation consiste a 
determiner si au moins un chemin est au moins partieliement disponible pour la 

25 transmission en mode non connecte. 

10. Procede de communication selon I'une quelconque des 
revendications 1 a 9, caracterise en ce que, au cours de I'operation d'estimation 
de disponibilite, on prend en compte des informations representatives des 
transmissions en mode connecte. 

30 11. Proc6de de communication selon Tune quelconque des 

revendications 1 £ 10, caracterise en ce que i'operation d'estimation est 
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independante des eventuelles transmissions en mode non connecte, issues 
d'autres dispositifs de communication du r6seau. 

12. Procede selon Tune quelconque des revendications 1 a 11, 
caracterise en ce que le reseau met en oeuvre le protocole de communication 
IEEE 1355. 

13. Procede selon Tune quelconque des revendications 1 a 12, 
caracterise en ce que Poperation de reservation comporte une operation de 
transmission (305) d'un message (251) comportant des informations 
representatives de chaque lien du chemin a reserver. 

14. Procede selon Tune quelconque des revendications 1 a 13, 
caracterise en ce que Poperation de reservation comporte : 

- une operation de diffusion (313) d'un message de mise a jour de 
table (253) a destination de tous les dispositifs de communication du reseau 
(802 a 809), et 

- pour chaque dispositif de communication du reseau qui n'est pas 
sur le chemin a reserver, une operation de mise a jour d'une table de charge 
(1504). 

15. Procede de communication selon Pune quelconque des 
revendications 1 & 14, caracterise en ce qu'il comporte, pour Petablissement 
d'une connexion : 

A/ effectuees par un dispositif de communication source 
d'information a transmettre en mode connecte : 

- une operation de determination de besoin de bande passante pour 
la transmission de ladite information en mode connecte, 

- une operation de determination d'un 6ventuel chemin disponible 
pour ladite transmission, en fonction d'informations conserv6es dans une table 
de charge de chaque lien du reseau, et 

- lorsqu'un chemin disponible est d§termin6 : 

• une operation d'§mission d'une information 
representative dudit besoin de bande passante & 
destination du dispositif de communication suivant sur 
ledit chemin, et 
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• une operation de mise a jour de ladite table de charge 
des liens du reseau, 

- une operation de diffusion a destination d'au moins tous les 
dispositifs de communication en dehors du chemin, d'une information 

5 representative dudit besoin de bande passante, 

B/ effectuees par chaque dispositif de • communication 
intermediate sur ledit chemin : 

- une operation de determination de disponibilite dudit chemin, 
pour ladite communication, en fonction d'informations conservees dans une 

10 table de charge de chaque lien du reseau, et 

- lorsque le chemin est disponible : 

• une operation d'emission d'une information 
representative dudit besoin de bande passante, au 
dispositif de communication suivant sur le chemin, et 

15 • une operation de mise a jour d'une table de charge des 

liens du reseau, 

CI effectuee par chaque dispositif de communication en dehors 
dudit chemin : 

- une operation de mise a jour d'une table de charge des liens du 

20 reseau. 

16. Proced6 de communication selon Tune quelconque des 
revendications 1 & 15, entre des dispositifs de communication susceptibles, 
chacun, de determiner le chemin a faire suivre a chaque information qu'il a a 
emettre, caracteris6 en ce qu'il comporte : 

25 - effectuee par chaque dispositif de communication dit "source", qui 

a besoin d'une connexion associee a un chemin, pour effectuer une 
transmission d'information a destination d'un dispositif de communication 
destinataire, une operation de demande de connexion, au cours de laquelle, le 
dispositif de communication source emet, a destination de chaque dispositif de 

30 communication dudit chemin, une demande d'6tablissement de connexion, 
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- lorsque I'etablissement de ladite connexion est possible, effectuee 
par au moins le dispositif de communication destinataire, une operation 
d'emission a destination du dispositif de communication source d'une 
acceptation de connexion, 

5 - effectuee par le dispositif de communication source, une operation 

de diffusion, a tous les dispositifs de communication du r6seau, d'une 
information representative de Tetablissement de la connexion, 

- effectuee par chaque dispositif de communication dudit chemin, a 
reception de ladite information representative d'etablissement de connexion, 

10 une operation de confirmation d'etablissement de ladite connexion, et 

- effectuee par chaque dispositif de communication en dehors dudit 
chemin, a reception de ladite information representative d'etablissement de 
connexion, une operation de mise en memoire d'une information repr6sentative 
de ladite connexion. 

15 17. Dispositif de communication sur un reseau £ commutation de 

paquet comportant au moins un commutateur (209), caracterise en ce qu'il 
comporte : 

- un moyen de determination de mode de transmission (204A, 
204B, 206A, 206B, 234, 236) adapte a determiner, pour chaque information a 

20 transmettre, un mode de transmission, connecte ou non, 

- un moyen de reservation (204A, 204B, 206A, 206B, 234, 236) 
adapte, pour chaque information a transmettre en mode connecte, a reserver 
un chemin sur ledit reseau, 

- un moyen d'estimation de disponibilite de chemin (204A, 204B, 
25 206A, 206B, 234, 236) adapte, pour chaque information a transmettre en mode 

non connecte, a estimer la disponibilite d'au moins un chemin, et 

- un moyen de transmission (204A, 204B, 206A, 206B f 234, 236) 
adapts, d'une part, a transmettre en mode connecte chaque information £ 
transmettre en mode connects, sur le chemin reserve par le moyen de 

30 reservation, et, d'autre part, & transmettre en mode non connecte, sur un 
chemin estim6 disponible par le moyen d'estimation de disponibilite, chaque 
information a transmettre en mode non connecte. 
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18. Dispositif de communication selon la revendication 17, 
caracterise en ce que le moyen de reservation est adapte a faire transmettre au 
moyen de transmission, sur ledit chemin, un message (251) comportant des 
informations representatives du service requis pour la transmission en mode 

5 connecte. 

19. Dispositif de communication selon Tune quelconque des 
revendications 17 ou 18, caracterise en ce qu'il comporte une memoire adaptee 
a conserver une table de charge (1100) et en ce que le moyen de reservation 
est adapte a mettre a jour ladite table de charge. 

10 20. Dispositif de communication selon la revendication 19, 

caracterise en ce que le moyen d'estimation est adapte a prendre en compte 
des valeurs conservees dans la table de charge (1100) pour estimer la 
disponibilite d'un chemin. 

21. Dispositif de communication selon Tune quelconque des 
15 revendications 19 ou 20, caracteris6 en ce que, pour mettre a jour la table de 

charge (1100), le moyen de reservation est adapte a determiner des 
parametres representatifs du service requis pour la transmission en mode 
connecte. 

22. Dispositif de communication selon Tune quelconque des 
20 revendications 19 a 21, caracterise en ce que, pour mettre a jour la table de 

charge (1100), le moyen de reservation est adapte a y conserver la bande 
passante disponible pour chaque lien (1001 a 1004) d'un chemin sortant (1011 
a 1013) du dispositif de communication considere. 

23. Dispositif de communication selon Tune quelconque des 
25 revendications 19 & 22, caracterise en ce que, pour mettre a jour la table de 

charge (1100), le moyen de reservation est adapte a y conserver la bande 
passante disponible pour chaque lien (1001 & 1007) du reseau faisant partie 
d'un chemin associe a une connexion (1011 a 1015). 

24. Dispositif de communication selon Tune quelconque des 
30 revendications 17 3 23, caract6ris6 en ce que, le moyen de reservation de 

chemin est adapts & faire verifier, par chaque dispositif de communication 
interm6diaire (803, 804) sur ledit chemin, la disponibilite du chemin a r6server. 
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25. Dispositif de communication selon Tune quelconque des 
revendications 17 a 24, caracterise en ce que le moyen d'estimation est adapts 
a determiner si au moins un chemin est au moins partiellement disponible pour 
la transmission en mode non connects. 
5 26. Dispositif de communication selon I'une quelconque des 

revendications 17 a 25, caracterise en ce que le moyen d'estimation est adapts 
a prendre en compte des informations representatives des transmissions en 
mode connecte. 

27. Dispositif de communication selon Tune quelconque des 
10 revendications 17 a 26, caracterise en ce que le moyen d'estimation est adapte 

a ne pas prendre en compte d'eventuelles transmissions en mode non 
connecte, issues d'autres dispositifs de communication du reseau. 

28. Dispositif selon Tune quelconque des revendications 17 a 27, 
caracterise en ce que le moyen de transmission est adapte a mettre en oeuvre 

15 le protocole de communication IEEE 1355. 

29. Dispositif selon Tune quelconque des revendications 17 a 28, 
caracterise en ce que le moyen de reservation est adapte a faire transmettre, 
par le moyen de transmission, un message (251) comportant des informations 
representatives de chaque lien du chemin a reserver pour chaque transmission 

20 en mode connecte. 

30. Dispositif selon I'une quelconque des revendications 17 a 29, 
caracterise en ce que le moyen de reservation est adapte a : 

- faire diffuser, par le moyen de transmission, un message de mise 
a jour (253) de table a destination de tous les dispositifs de communication du 

25 reseau, et 

- lorsque le dispositif de communication qui comporte ledit moyen 
de reservation, regoit un tel message, et qu'il n'est pas sur le chemin d r6server, 
a mettre a jour une table de charge. 

31. Dispositif de communication selon Tune quelconque des 
30 revendications 17 a 30, caracterise en ce qu'il : 

- comporte une memoire adaptee £ conserver une table de charge 
contenant des informations relatives £ la charge de chaque lien du r6seau, et 
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- est adapte, pour I'etablissement d'une connexion : 
pour la transmission conformation en mode connecte : 

- a determiner un besoin de bande passante pour la transmission de 
ladite information en mode connecte, 

5 - a determiner un 6ventuel chemin disponible pour ladite 

transmission, en fonction d'informations conservees dans ladite table de 
charge, 

et lorsqu'un chemin disponible est determine, 

- a faire emettre, au moyen de transmission, une information 
10 representative dudit besoin de bande passante, a destination du dispositif de 

communication suivant sur ledit chemin, 

- a mettre a jour ladite table de charge, 

- a faire diffuser, par le moyen de transmission, a destination d'au 
moins tous les dispositifs de communication en dehors du chemin, une 

15 information representative dudit besoin de bande passante. 

32. Dispositif de communication selon Tune quelconque des 
revendications 17 a 31, sur un reseau comportant des dispositifs de 
communication susceptibles, chacun, de determiner le chemin a faire suivre a 
chaque information qu'il a a emettre, caracterise en ce qu'il est adapte, lorsqu'il 

20 a besoin d'une connexion associ6e a un chemin, pour effectuer une 
transmission d'information & destination d'un dispositif de communication 
destinataire : 

- a faire emettre, par le moyen de transmission, a destination de 
chaque dispositif de communication dudit chemin, un message de demande 

25 d'etablissement de connexion, et 

- a reception d'un message d'acceptation de connexion en 
provenance du dispositif de communication destinataire, a faire diffuser, par 
ledit moyen de transmission, & tous les dispositifs de communication du reseau, 
un message d'informations d'6tablissement de la connexion. 

30 33. Ordinateur, caract6ris6 en ce qu'il comporte un dispositif de 

communication selon Tune quelconque des revendications 17 a 32. 
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34. Camera, caracterisee en ce qu'elle comporte un dispositif de 
communication selon Tune quelconque des revendications 17 a 32. 

35. Telecopieur, caracterise en ce qu'il comporte un dispositif de 
communication selon Tune quelconque des revendications 17 a 32. 

5 36. Appareil photographique, caracterise en ce qu'il comporte un 

dispositif de communication selon Tune quelconque des revendications 17 a 32. 

37. Televiseur, caracterise en ce qu'il comporte un dispositif de 
communication selon Tune quelconque des revendications 17 a 32. 

38. Imprimante, caracterisee en ce qu'elle comporte un dispositif de 
10 communication selon Tune quelconque des revendications 17 a 32. 

39. Scanner, caracterise en ce qu'il comporte un dispositif de 
communication selon Tune quelconque des revendications 17 a 32. 

40. Lecteur audio/video, caracterise en ce qu'il comporte un 
dispositif de communication selon Tune quelconque des revendications 17 a 32. 
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